今天给大家分享19道Java后端面试题及答案，下面是完整的Java后端面试题详解，希望对大家有所帮助@mikechen
Spring MVC 模型怎么理解？
可以用如下的图形来表示MVC三者之间的关系：
1.模型(Model)
模型封装了数据及对数据的操作，可以直接对数据库进行访问，不依赖视图和控制器，也就是说模型并不关注数据如何展示，只负责提供数据。GUI 程序模型中数据的变化一般会通过观察者模式通知视图，而在 web 中则不会这样。
2.视图(View)
视图从模型中拉取数据，只负责展示，没有具体的程序逻辑。
3.控制器(Controller)
控制器用于控制程序的流程，将模型中的数据展示到视图中。
SpringMVC执行流程是什么？
(1)用户发送请求发送给前端控制器
(2)前端控制器收到请求调用处理器映射器
(3)处理器映射器找到具体得处理器，生成处理器对象以及处理器拦截器并返回给前端控制器
(4)前端控制器调用处理器适配器
(5)处理器适配器经过适配调用具体得处理器
(6)处理器执行完成并返回结果给前端控制器
(7)前端控制器接受到结果，并讲结果传给视图解析器
Spring IOC的实现原理?
IOC容器其实就是一个大工厂，它用来管理我们所有的对象以及依赖关系。
- 原理就是通过 Java 的反射技术来实现的，通过反射我们可以获取类的所有信息(成员变量、类名等等等)；
- 再通过配置文件(xml)或者注解来描述类与类之间的关系。
这样我们就可以通过这些配置信息和反射技术来构建出对应的对象和依赖关系了，如下图所示：
SpringBoot、Spring MVC和Spring有什么区别？
1）Spring
Spring最重要的特征是依赖注入。所有Spring Modules不是依赖注入就是IOC控制反转，当我们恰当的使用DI或者是IOC的时候，可以开发松耦合应用。
2）Spring MVC
Spring MVC提供了一种分离式的方法来开发Web应用。通过运用像DispatcherServelet，MoudlAndView 和 ViewResolver 等一些简单的概念，开发 Web 应用将会变的非常简单。
3）SpringBoot
Spring和Spring MVC的问题在于需要配置大量的参数，SpringBoot通过一个自动配置和启动的项来解决这个问题。
Java线程状态的控制？
可以对照上面的线程状态流转图来看具体的方法，这样更清楚具体作用：
1.start()
启动当前线程, 调用当前线程的run()方法
2.run()
通常需要重写Thread类中的此方法, 将创建的线程要执行的操作声明在此方法中
3.yield()
释放当前CPU的执行权
4.join()
在线程a中调用线程b的join(), 此时线程a进入阻塞状态, 知道线程b完全执行完以后, 线程a才结束阻塞状态
5.sleep(long militime)
让线程睡眠指定的毫秒数，在指定时间内，线程是阻塞状态
6.wait()
一旦执行此方法，当前线程就会进入阻塞，一旦执行wait()会释放同步监视器。
7.sleep()和wait()的异同
相同点：两个方法一旦执行，都可以让线程进入阻塞状态。
不同点：
1) 两个方法声明的位置不同：Thread类中声明sleep(),Object类中声明wait()
2) 调用要求不同：sleep()可以在任何需要的场景下调用。wait()必须在同步代码块中调用。
2) 关于是否释放同步监视器：如果两个方法都使用在同步代码块呵呵同步方法中，sleep不会释放锁，wait会释放锁。
8.notify()
一旦执行此方法，将会唤醒被wait的一个线程。如果有多个线程被wait，就唤醒优先度最高的。
9.notifyAll()
一旦执行此方法，就会唤醒所有被wait的线程 。
10.LockSupport
LockSupport.park()和LockSupport.unpark()实现线程的阻塞和唤醒的。
Java同步有几种实现方法?
同步的实现方面有五种，分别是synchronized、wait与notify、sleep、suspend、join
synchronized: 一直持有锁，直至执行结束
wait():使一个线程处于等待状态，并且释放所持有的对象的lock，需捕获异常。
sleep():使一个正在运行的线程处于睡眠状态，是一个静态方法，需捕获异常，不释放锁。
notify():唤醒一个处于等待状态的线程，注意的是在调用此方法的时候，并不能确切的唤醒某一个等待状态的线程，而是由JVM确定唤醒哪个线程，而且不是按优先级。
notityAll():唤醒所有处入等待状态的线程，注意并不是给所有唤醒线程一个对象的锁，而是让它们竞争。
Java线程的生命周期?
在线程的生命周期中，它要经过新建(New)、就绪（Runnable）、运行（Running）、阻塞(Blocked)和死亡(Dead)5种状态
- 新建状态：当程序使用new关键字创建了一个线程之后，该线程就处于新建状态，此时仅由JVM为其分配内存，并初始化其成员变量的值
- 就绪状态：当线程对象调用了start()方法之后，该线程处于就绪状态。Java虚拟机会为其创建方法调用栈和程序计数器，等待调度运行
- 运行状态：如果处于就绪状态的线程获得了CPU，开始执行run()方法的线程执行体，则该线程处于运行状态
- 阻塞状态：当处于运行状态的线程失去所占用资源之后，便进入阻塞状态
- 死亡状态：线程在run()方法执行结束后进入死亡状态。此外，如果线程执行了interrupt()或stop()方法，那么它也会以异常退出的方式进入死亡状态。
面向对象的特征有哪些方面？
1. 封装，隐藏内部实现，只暴露公共行为
2. 继承，提高代码的重用性
3. 多态，体现现实生活中相似对象的差异性
4. 抽象，抽取现实世界中相似对象的共同点
重载Overload和Override重写的区别？
Overload是重载的意思，Override是覆盖的意思，也就是重写。
重载和重写有共同之处，两个方法的方法名都必须相同，如果不同，既不构成重载，也不构成重写。
1. 重写必须发生在父子类之间，重载可以不在父子类之间
2. 重写的特点：
a) 参数列表完全相同：个数相同、类型相同、顺序相同
b) 子类的返回值不能比父类的返回值范围大
c) 子类方法抛出的异常不能比父类方法抛出的异常范围大
d) 修饰符只能为public、protected、friendly，不能为private
e) 父子类方法不能使用static修饰
3. 重载发生在同一个类或父子类之间，重写中参数列表至少满足个数不同、类型不同、顺序不同中的一个条件，不包含父子类之间的static方法
HashMap和Hashtable的区别?
1. 线程同步，Hashtable线程安全，HashMap线程不安全
2. 效率问题，Hashtable效率低，HashMap效率高
3. HashMap可以使用null作为key，Hashtable不可以使用null为key
4. HashMap使用的是新实现，继承AbstractMap，而Hashtable是继承Dictionary类，实现比较老
5. Hash算不同，HashMap的hash算法比Hashtable的hash算法效率高
6. HashMap把Hashtable的contains方法去掉了，改成containsValue和containsKey。因为contains方法容易让人引起误解。
7. 取值不同，HashMap用的是Iterator接口，而Hashtable中还有使用Enumeration接口
常用的Map集合有哪些？
常用的Map集合：HashMap、HashTable、LinkedHashMap、ConcurrentHashMap。
HashMap是线程安全的？有哪些线程安全的？
HashMap不是线程安全的，线程安全的有HashTable、ConcurrentHashMap、SynchronizedMap，性能最好的是ConcurrentHashMap。
Spring体系结构
Spring框架至今已集成了20多个模块，这些模块分布在以下模块中：
- 核心容器（Core Container）
- 数据访问/集成（Data Access/Integration）层
- Web层
- AOP（Aspect Oriented Programming）模块
- 植入（Instrumentation）模块
- 消息传输（Messaging）
- 测试（Test）模块
Spring体系结构如下图：
Spring框架的好处是什么？
- 轻量：Spring是轻量的，基本的版本大约2MB。
- 控制反转：Spring通过控制反转实现了松散耦合，对象们给出它们的依赖，而不是创建或查找依赖的对象们。
- 面向切面的编程(AOP)：Spring支持面向切面的编程，并且把应用业务逻辑和系统服务分开。
- 容器：Spring包含并管理应用中对象的生命周期和配置。
- MVC框架：Spring的WEB框架是个精心设计的框架，是Web框架的一个很好的替代品。
- 事务管理：Spring提供一个持续的事务管理接口，可以扩展到上至本地事务下至全局事务（JTA）。
- 异常处理：Spring提供方便的API把具体技术相关的异常（比如由JDBC，HibernateorJDO抛出的）转化为一致的unchecked异常。
Spring七大功能模块
Spring有七大功能模块，分别是Spring Core，AOP，ORM，DAO，MVC，WEB，Context。
JVM内存模型
首先我们来了解一下JVM的内存模型的怎么样的：
- 堆得内存由-Xms指定，默认是物理内存的1/64；最大的内存由-Xmx指定，默认是物理内存的1/4。
- 默认空余的堆内存小于40%时，就会增大，直到-Xmx设置的内存。具体的比例可以由-XX:MinHeapFreeRatio指定
- 空余的内存大于70%时，就会减少内存，直到-Xms设置的大小。具体由-XX:MaxHeapFreeRatio指定。
2.虚拟机栈
虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame）用于存储局部变量表、操作栈、动态链接、方法出口等信息本地方法栈：本地方法栈则是为虚拟机使用到的Native方法服务。
3.方法区：存储已被虚拟机加载的类元数据信息(元空间)
1）有时候也成为永久代，在该区内很少发生垃圾回收，但是并不代表不发生GC，在这里进行的GC主要是对方法区里的常量池和对类型的卸载
2）方法区主要用来存储已被虚拟机加载的类的信息、常量、静态变量和即时编译器编译后的代码等数据。
该区域是被线程共享的。
3）方法区里有一个运行时常量池，用于存放静态编译产生的字面量和符号引用。该常量池具有动态性，也就是说常量并不一定是编译时确定，运行时生成的常量也会存在这个常量池中。
4.程序计数器：当前线程所执行的字节码的行号指示器
总结：
JVM加载class文件的原理机制?
1. 查找当前ClassLoader中是否有此class的类对象，有则返回
2. 若没有的话，向上递归所有的父ClassLoader中有无此class类对象，有则返回
3. 若还没有，查找BootstrapClassLoader中有无此class类对象，有则返回
4. 若还没有的话，使用findClass或resolveClass加载类对象
a. 读取class二进制文件
b. 根据字节数组生成Class对象
c. 缓存到当前ClassLoader中
JVM加载class对象是懒加载，按需加载
JVM垃圾回收算法
1.标记-清除: 这是垃圾收集算法中最基础的，根据名字就可以知道，它的思想就是标记哪些要被回收的对象，然后统一回收。这种方法很简单，但是会有两个主要问题：1.效率不高，标记和清除的效率都很低；2.会产生大量不连续的内存碎片，导致以后程序在分配较大的对象时，由于没有充足的连续内存而提前触发一次GC动作。
2.复制算法: 为了解决效率问题，复制算法将可用内存按容量划分为相等的两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存，再将第二块上的对象复制到第一块。但是这种方式，内存的代价太高，每次基本上都要浪费一般的内存。 于是将该算法进行了改进，内存区域不再是按照1：1去划分，而是将内存划分为8:1:1三部分，较大那份内存交Eden区，其余是两块较小的内存区叫Survior区。每次都会优先使用Eden区，若Eden区满，就将对象复制到第二块内存区上，然后清除Eden区，如果此时存活的对象太多，以至于Survivor不够时，会将这些对象通过分配担保机制复制到老年代中。(java堆又分为新生代和老年代)
3. 标记-整理 该算法主要是为了解决标记-清除，产生大量内存碎片的问题；当对象存活率较高时，也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回收对象移动到一端，然后清除掉端边界以外的对象，这样就不会产生内存碎片了。
4.分代收集 现在的虚拟机垃圾收集大多采用这种方式，它根据对象的生存周期，将堆分为新生代和老年代。在新生代中，由于对象生存期短，每次回收都会有大量对象死去，那么这时就采用复制算法。老年代里的对象存活率较高，没有额外的空间进行分配担保，所以可以使用标记-整理 或者 标记-清除。
JVM垃圾收集器有哪些？以及优劣势比较？
1.串行收集器
串行收集器是最简单的，它设计为在单核的环境下工作（32位或者windows），你几乎不会使用到它。它在工作的时候会暂停整个应用的运行，因此在所有服务器环境下都不可能被使用。
使用方法：-XX:+UseSerialGC
2.并行收集器
这是JVM默认的收集器，跟它名字显示的一样，它最大的优点是使用多个线程来扫描和压缩堆。缺点是在minor和full GC的时候都会暂停应用的运行。并行收集器最适合用在可以容忍程序停滞的环境使用，它占用较低的CPU因而能提高应用的吞吐（throughput）。
使用方法：-XX:+UseParallelGC
3.CMS收集器
CMS是Concurrent-Mark-Sweep的缩写，并发的标记与清除。
这个算法使用多个线程并发地（concurrent）扫描堆，标记不使用的对象，然后清除它们回收内存。在两种情况下会使应用暂停（Stop the World, STW）：
1. 当初次开始标记根对象时initial mark。
2. 当在并行收集时应用又改变了堆的状态时，需要它从头再确认一次标记了正确的对象final remark。
这个收集器最大的问题是在年轻代与老年代收集时会出现的一种竞争情况（race condition），称为提升失败promotion failure。对象从年轻代复制到老年代称为提升promotion，但有时侯老年代需要清理出足够空间来放这些对象，这需要一定的时间，它收集的速度可能赶不上不断产生的要提升的年轻代对象的速度，这时就需要做STW的收集。STW正是CMS想避免的问题。为了避免这个问题，需要增加老年代的空间大小或者增加更多的线程来做老年代的收集以赶上从年轻代复制对象的速度。
除了上文所说的内容之外，CMS最大的问题就是内存空间碎片化的问题。CMS只有在触发FullGC的情况下才会对堆空间进行compact。如果线上应用长时间运行，碎片化会非常严重，会很容易造成promotion failed。为了解决这个问题线上很多应用通过定期重启或者手工触发FullGC来触发碎片整理。
对比并行收集器它的一个坏处是需要占用比较多的CPU。对于大多数长期运行的服务器应用来说，这通常是值得的，因为它不会导致应用长时间的停滞。但是它不是JVM的默认的收集器。
4.G1收集器
如果你的堆内存大于4G的话，那么G1会是要考虑使用的收集器。它是为了更好支持大于4G堆内存在JDK 7 u4引入的。G1收集器把堆分成多个区域，大小从1MB到32MB，并使用多个后台线程来扫描这些区域，优先会扫描最多垃圾的区域，这就是它名称的由来，垃圾优先Garbage First。
如果在后台线程完成扫描之前堆空间耗光的话，才会进行STW收集。它另外一个优点是它在处理的同时会整理压缩堆空间，相比CMS只会在完全STW收集的时候才会这么做。
使用过大的堆内存在过去几年是存在争议的，很多开发者从单个JVM分解成使用多个JVM的微服务（micro-service）和基于组件的架构。其他一些因素像分离程序组件、简化部署和避免重新加载类到内存的考虑也促进了这样的分离。
除了这些因素，最大的因素当然是避免在STW收集时JVM用户线程停滞时间过长，如果你使用了很大的堆内存的话就可能出现这种情况。另外，像Docker那样的容器技术让你可以在一台物理机器上轻松部署多个应用也加速了这种趋势。
使用方法：－XX:+UseG1GC
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注「mikechen」公众号，获取更多技术干货！
后台回复【面试】即可获取《史上最全阿里Java面试题总结》，后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》