什么是微服务？
1服务拆分粒度更细
微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
2服务独立部署
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。
3服务独立维护，分工明确
每个微服务都可以交由一个小团队进行开发，测试维护部署，并对整个生命周期负责。比如在单体应用时期，我们的研发团队是如下图这样传统的水平架构：
4水平团队组织架构
而微服务时期，我们可以根据其思想把团队划分成垂直组织架构：
当然，这种垂直划分只是一个理想的架构，实际在企业中并不会把团队组织架构拆分得这么绝对。
Spring Boot、Spring MVC 和 Spring 有什么区别？
分别描述各自的特征：
Spring 框架就像一个家族，有众多衍生产品例如 boot、security、jpa等等；但他们的基础都是Spring 的ioc和 aop，ioc 提供了依赖注入的容器， aop解决了面向切面编程，然后在此两者的基础上实现了其他延伸产品的高级功能。
Spring MVC提供了一种轻度耦合的方式来开发web应用；它是Spring的一个模块，是一个web框架；通过DispatcherServlet, ModelAndView 和 View Resolver，开发web应用变得很容易；解决的问题领域是网站应用程序或者服务开发——URL路由、Session、模板引擎、静态Web资源等等。
Spring Boot实现了auto-configuration自动配置（另外三大神器actuator监控，cli命令行接口，starter依赖），降低了项目搭建的复杂度。它主要是为了解决使用Spring框架需要进行大量的配置太麻烦的问题，所以它并不是用来替代Spring的解决方案，而是和Spring框架紧密结合用于提升Spring开发者体验的工具；同时它集成了大量常用的第三方库配置(例如Jackson, JDBC, Mongo, Redis, Mail等等)，Spring Boot应用中这些第三方库几乎可以零配置的开箱即用(out-of-the-box)。
所以，用最简练的语言概括就是:
Spring 是一个“引擎”;
Spring MVC 是基于Spring的一个 MVC 框架;
Spring Boot 是基于Spring4的条件注册的一套快速开发整合包。
Spring Boot 核心功能
1）独立运行的 Spring 项目
Spring Boot 可以以 jar 包的形式独立运行，运行一个 Spring Boot 项目只需通过 java–jar xx.jar 来运行。
2）内嵌 Servlet 容器
Spring Boot 可选择内嵌 Tomcat、Jetty 或者 Undertow，这样我们无须以 war 包形式部署项目。
3）提供 starter 简化 Maven 配置
Spring 提供了一系列的 starter pom 来简化 Maven 的依赖加载，例如，当你使用了spring-boot-starter-web 时，会自动加入如图 1 所示的依赖包。
4）自动配置 Spring
Spring Boot 会根据在类路径中的 jar 包、类，为 jar 包里的类自动配置 Bean，这样会极大地减少我们要使用的配置。当然，Spring Boot 只是考虑了大多数的开发场景，并不是所有的场景，若在实际开发中我们需要自动配置 Bean，而 Spring Boot 没有提供支持，则可以自定义自动配置。
5）准生产的应用监控
Spring Boot 提供基于 http、ssh、telnet 对运行时的项目进行监控。
6）无代码生成和 xml 配置
Spring Boot 的神奇的不是借助于代码生成来实现的，而是通过条件注解来实现的，这是 Spring 4.x 提供的新特性。Spring 4.x 提倡使用 Java 配置和注解配置组合，而 Spring Boot 不需要任何 xml 配置即可实现 Spring 的所有配置。
Spring Boot的优缺点
1）优点
快速构建项目。
对主流开发框架的无配置集成。
项目可独立运行，无须外部依赖Servlet容器。
提供运行时的应用监控。
极大地提高了开发、部署效率。
与云计算的天然集成。
2）缺点
版本迭代速度很快，一些模块改动很大。
由于不用自己做配置，报错时很难定位。
网上现成的解决方案比较少。
sql 中 ${} 和 #{}的区别：
#将传入的参数都当成一个字符串，会对自动传入的数据加一个双引号。如：order by #{age}，如果传入的值是18,那么解析成sql时的值为order by “18”, 如果传入 age ,则会解析为 order by “age”{age}，如果传入的值是18,那么解析成sql时的值为order by 18, 如果传入的值是age，则解析成的sql为order by age
#方式底层采用预编译方式PreparedStatement，能够很大程度防止sql注入；$方式底层只是Statement，无法防止Sql注入。
KaTeX parse error: Expected 'EOF', got '#' at position 27: …对象，例如传入表名. 一般能用#̲的就别用
Spring MVC 的运行流程：
用户发起请求到前端控制器（DispatcherServlet），该控制器会过滤出哪些请求可以访问Servlet、哪些不能访问。就是url-pattern的作用，并且会加载springmvc.xml配置文件。
前端控制器会找到处理器映射器（HandlerMapping），通过HandlerMapping完成url到controller映射的组件，简单来说，就是将在springmvc.xml中配置的或者注解的url与对应的处理类找到并进行存储，用map<url,handler>这样的方式来存储。
HandlerMapping有了映射关系，并且找到url对应的处理器，HandlerMapping就会将其处理器（Handler）返回，在返回前，会加上很多拦截器。
DispatcherServlet拿到Handler后，找到HandlerAdapter（处理器适配器），通过它来访问处理器，并执行处理器。
执行处理器
处理器会返回一个ModelAndView对象给HandlerAdapter
通过HandlerAdapter将ModelAndView对象返回给前端控制器(DispatcherServlet)
前端控制器请求视图解析器(ViewResolver)去进行视图解析，根据逻辑视图名解析成真正的视图(jsp)，其实就是将ModelAndView对象中存放视图的名称进行查找，找到对应的页面形成视图对象
返回视图对象到前端控制器。
视图渲染，就是将ModelAndView对象中的数据放到request域中，用来让页面加载数据的。
通过第8步，通过名称找到了对应的页面，通过第10步，request域中有了所需要的数据，那么就能够进行视图渲染了。最后将其返回即可。
Spring MVC 常用的 5 个注解：
@Controller：@Controller 用于标记在一个类上，使用它标记的类就是一个SpringMVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。
@RequestMapping ：@RequestMapping是一个用来处理请求地址映射的注解，可用于类或方法上。用于类上，表示类中的所有响应请求的方法都是以该地址作为父路径。用于方法上，方法的返回值会通过视图解析器解析为实际的物理视图。
@ResponseBody：@ResponseBody用于将Controller的方法返回的对象，通过适当的HttpMessageConverter转换为指定格式后，写入到Response对象的body数据区。
注意：返回的数据是其他某种格式的数据时（如json、xml等）才使用；
@RequestParam：@RequestParam用于将请求参数区数据映射到功能处理方法的参数上，用例：
@RequestMapping("/testRequestParam")
public String testRequestParam(@RequestParam(“id”) int id) {
System.out.println("testRequestParam " + id);
return “success”;
}
@Resource和@Autowired：都是做bean的注入时使用
共同点：两者都可以写在字段和setter方法上。两者如果都写在字段上，那么就不需要再写setter方法。
不同点：
@Autowired为Spring提供的注解，需要导入包org.springframework.beans.factory.annotation.Autowired;@Autowired注解是按照类型（byType）装配依赖对象，默认情况下它要求依赖对象必须存在，如果允许null值，可以设置它的required属性为false。如果我们想使用按照名称（byName）来装配，可以结合@Qualifier注解一起使用。如下：public class HelloWorld{
@Autowired
@Qualifier(“userDao”)
private UserDao userDao;
}
@Resource并不是Spring的注解，它的包是javax.annotation.Resource，需要导入，但是Spring支持该注解的注入。@Resource默认按照ByName自动注入，由J2EE提供，需要导入包javax.annotation.Resource。@Resource有两个重要的属性：name和type，而Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以，如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不制定name也不制定type属性，这时将通过反射机制使用byName自动注入策略。
注意：最好是将@Resource放在setter方法上，因为这样更符合面向对象的思想，通过set、get去操作属性，而不是直接去操作属性。
IOC，AOP的实现原理：
IOC：控制反转，是一种设计模式。一层含义是控制权的转移：由传统的在程序中控制依赖转移到由容器来控制；第二层是 依赖注入 （DI）
DI：依赖注入，将相互依赖的对象分离，在spring配置文件中描述他们的依赖关系，调用setter方法来注入（反射的话太消耗性能）。他们的依赖关系只在使用的时候才建立。简单来说就是不需要总是NEW一个对象了，只需要一个或多个对象（由你定义的策略决定，一般是单例），统一由容器进行管理。
AOP：面向切面，是一种编程思想，是对OOP面向对象的补充和完善。将系统中非核心的业务提取出来，进行单独处理。比如事务、日志和安全等。这个简单来说就是可以在一段程序之前或者之后做一些事。 实现AOP的技术，主要分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行（jdk动态代理：必须至少实现一个接口，底层利用反射机制，效率较低；cglib动态代理：原理是使用ASM字节码技术对指定的业务类生成一个子类，并覆盖业务方法实现代理，采用继承的方式，所以不能对final修改的类进行代理）；二是采用静态代理的方式，在代码中显示地实现一个业务实现类的指定代理，在代理类中对同名的业务方法进行包装（不修改原有的业务代码），用户通过代理类调用被包装过的业务方法，但会导致代码冗余。目前这几种代理方式并没有高低之分，只是应用的场景不同。
Spring 的AOP和IOC都是为了解决系统代码耦合度过高的问题。使代码重用度高、易于维护。
AOP和IOC并不是spring中特有的，只是spring把他们应用的更灵活方便。
Spring DI 常用的三种方式：
常用的注入方式主要有三种：构造方法注入，setter注入，接口注入。
Java 8 新特性
Lambda 表达式 − Lambda 允许把函数作为一个方法的参数（函数作为参数传递到方法中）。
方法引用 − 方法引用提供了非常有用的语法，可以直接引用已有Java类或对象（实例）的方法或构造器。与lambda联合使用，方法引用可以使语言的构造更紧凑简洁，减少冗余代码。
默认方法 − 默认方法就是一个在接口里面有了一个实现的方法。
新工具 − 新的编译工具，如：Nashorn引擎 jjs、 类依赖分析器jdeps。
Stream API −新添加的Stream API（java.util.stream） 把真正的函数式编程风格引入到Java中。
Date Time API − 加强对日期与时间的处理。
Optional 类 − Optional 类已经成为 Java 8 类库的一部分，用来解决空指针异常。
Nashorn, JavaScript 引擎 − Java 8提供了一个新的Nashorn javascript引擎，它允许我们在JVM上运行特定的javascript应用
什么是线程池？
线程池是一种多线程处理形式，处理过程中将任务提交到线程池，任务的执行交由线程池来管理。
如果每个请求都创建一个线程去处理，那么服务器的资源很快就会被耗尽，使用线程池可以减少创建和销毁线程的次数，每个工作线程都可以被重复利用，可执行多个任务。
为什么要使用线程池？
创建线程和销毁线程的花销是比较大的，这些时间有可能比处理业务的时间还要长。这样频繁的创建线程和销毁线程，再加上业务工作线程，消耗系统资源的时间，可能导致系统资源不足。（我们可以把创建和销毁的线程的过程去掉）
线程池有什么作用？
线程池作用就是限制系统中执行线程的数量。
1、提高效率 创建好一定数量的线程放在池中，等需要使用的时候就从池中拿一个，这要比需要的时候创建一个线程对象要快的多。
2、方便管理 可以编写线程池管理代码对池中的线程同一进行管理，比如说启动时有该程序创建100个线程，每当有请求的时候，就分配一个线程去工作，如果刚好并发有101个请求，那多出的这一个请求可以排队等候，避免因无休止的创建线程导致系统崩溃。
说说几种常见的线程池及使用场景
1、newSingleThreadExecutor
创建一个单线程化的线程池，它只会用唯一的工作线程来执行任务，保证所有任务按照指定顺序(FIFO, LIFO, 优先级)执行。
2、newFixedThreadPool
创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
3、newCachedThreadPool
创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
4、newScheduledThreadPool
创建一个定长线程池，支持定时及周期性任务执行。
线程池中的几种重要的参数
corePoolSize就是线程池中的核心线程数量，这几个核心线程，只是在没有用的时候，也不会被回收
maximumPoolSize就是线程池中可以容纳的最大线程的数量
keepAliveTime，就是线程池中除了核心线程之外的其他的最长可以保留的时间，因为在线程池中，除了核心线程即使在无任务的情况下也不能被清 除，其余的都是有存活时间的，意思就是非核心线程可以保留的最长的空闲时间，
util，就是计算这个时间的一个单位。
workQueue，就是等待队列，任务可以储存在任务队列中等待被执行，执行的是FIFIO原则（先进先出）。
threadFactory，就是创建线程的线程工厂。
handler,是一种拒绝策略，我们可以在任务满了之后，拒绝执行某些任务。
说说线程池的拒绝策略
当请求任务不断的过来，而系统此时又处理不过来的时候，我们需要采取的策略是拒绝服务。RejectedExecutionHandler接口提供了拒绝任务处理的自定义方法的机会。在ThreadPoolExecutor中已经包含四种处理策略。
AbortPolicy策略：该策略会直接抛出异常，阻止系统正常工作。
CallerRunsPolicy 策略：只要线程池未关闭，该策略直接在调用者线程中，运行当前的被丢弃的任务。
DiscardOleddestPolicy策略： 该策略将丢弃最老的一个请求，也就是即将被执行的任务，并尝试再次提交当前任务。
DiscardPolicy策略：该策略默默的丢弃无法处理的任务，不予任何处理。
除了JDK默认提供的四种拒绝策略，我们可以根据自己的业务需求去自定义拒绝策略，自定义的方式很简单，直接实现RejectedExecutionHandler接口即可。
说一下 jvm 的主要组成部分？及其作用？
类加载器（ClassLoader）
运行时数据区（Runtime Data Area）
执行引擎（Execution Engine）
本地库接口（Native Interface）
组件的作用： 首先通过类加载器（ClassLoader）会把 Java 代码转换成字节码，运行时数据区（Runtime Data Area）再把字节码加载到内存中，而字节码文件只是 JVM 的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器执行引擎（Execution Engine），将字节码翻译成底层系统指令，再交由 CPU 去执行，而这个过程中需要调用其他语言的本地库接口（Native Interface）来实现整个程序的功能。
@Autowired 与@Resource的区别：
1、 @Autowired与@Resource都可以用来装配bean. 都可以写在字段上,或写在setter方法上。
2、 @Autowired默认按类型装配（这个注解是属业spring的），默认情况下必须要求依赖对象必须存在，如果要允许null值，可以设置它的required属性为false，如：@Autowired(required=false) ，如果我们想使用名称装配可以结合@Qualifier注解进行使用
redis
Redis五大数据类型的常用操作
v阅读目录
vString(字符串)
vHash(哈希)
vList(列表)
vSet(集合)
vZset(sorted set：有序集合)
怎么保证缓存和数据库数据的一致性？
合理设置缓存的过期时间。
新增、更改、删除数据库操作时同步更新 Redis，可以使用事物机制来保证数据的一致性。
redis 持久化有几种方式？
Redis 的持久化有两种方式，或者说有两种策略：
RDB（Redis Database）：指定的时间间隔能对你的数据进行快照存储。
AOF（Append Only File）：每一个收到的写命令都通过write函数追加到文件中。
redis 如何做内存优化？
尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。
比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。
redis 常见的性能问题有哪些？该如何解决？
主服务器写内存快照，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以主服务器最好不要写内存快照。
Redis 主从复制的性能问题，为了主从复制的速度和连接的稳定性，主从库最好在同一个局域网内
什么是缓存穿透？怎么解决？
缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。
解决方案：最简单粗暴的方法如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们就把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
springmvc 中的拦截器是由实现 HandlerInterceptor 或者继承 HandlerInterceptorAdapter 来实现的。
自定义实现一个拦截器的步骤：
a). 定义一个实现 HandlerInterceptor 接口 的类
从写preHandle，postHandle，afterCompletion方法
b) 在 springmvc 的配置文件中 ，添加拦截器配置mvc:interceptors
定义一个拦截器的配置
mvc:interceptor
mapping 指定哪些url被拦截
/*表示根路径下的所有请求被拦截-/hello.do
/表示根路径及其子路径下的所有请求被拦截/user/add.do
<mvc:mapping path="/"/>
配置拦截器的路径
</mvc:interceptor>
</mvc:interceptors>
Java中final、finally、finalize的区别
final用于声明属性，方法和类，分别表示属性不可交变，方法不可覆盖，类不可继承。
finally是异常处理语句结构的一部分，表示总是执行。
finalize是Object类的一个方法，在垃圾收集器执行的时候会调用被回收对象的此方法，供垃圾收集时的其他资源回收，例如关闭文件等。
为什么用单例多例： 之所以用单例，是因为没必要每个请求都新建一个对象，这样子既浪费CPU又浪费内存； 之所以用多例，是为了防止并发问题；即一个请求改变了对象的状态，此时对象又处理另一个请求，而之前请求对对象状态的改变导致了对象对另一个请求做了错误的处理； 用单例和多例的标准只有一个： 当对象含有可改变的状态时（更精确的说就是在实际应用中该状态会改变），则多例，否则单例；
使用arraylist需要注意什么？
尽量使用new ArrayList创建List对象，不要用Arrays.asList创建List对象，因为Arrays.asList创建List对象是通过Arrays的内部类继承AbstractList类获取List对象，但是没有对AbstractList类中的add、remove等方法进行重写，当使用这些方法时会报UnsupportedOperationException()异常。
基本类型与包装类型的异同：
1、在Java中，一切皆对象，但八大基本类型却不是对象。
2、声明方式的不同，基本类型无需通过new关键字来创建，而封装类型则需new关键字。
3、存储方式及位置的不同，基本类型是直接存储变量的值，保存在堆栈中能高效的存取；封装类型需要通过引用指向实例，具体的实例保存在堆中；
4、初始值的不同，封装类型的初始值为null，基本类型的的初始值视具体的类型而定，比如int类型的初始值为0，boolean类型为false；
5、使用方式的不同，比如与集合类合作使用时只能使用包装类型。
6、什么时候该用包装类，什么时候该用基本类型，看基本的业务来定：这个字段允不允许null值，如果允许，则必然要用封装类；否则，基本类型就可以了。如果用到比如泛型和反射调用函数，就需要用包装类！
mysqlvarchar是按照什么计量单位字节还是字符？
也就是version4之前，按字节；
version5之后，按字符。
