OSI七层模型 #

OSI七层模型一般指开放系统互连参考模型 (Open System Interconnect 简称OSI)是国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)联合制定的开放系统互连参考模型，为开放式互连信息系统提供了一种功能结构的框架。

具体如下：

- 应用层：各种应用程序协议，比如 HTTP、HTTPS、FTP、SOCKS 安全套接字协议、DNS 域名系统、GDP 网关发现协议等。

- 表示层：加密解密、转换翻译、压缩解压缩，比如 LPP 轻量级表示协议。

- 会话层：不同机器上的用户建立和管理会话，比如 SSL 安全套接字层协议、TLS 传输层安全协议、RPC 远程过程调用协议等。

- 传输层：接收上一层的数据，在必要的时候对数据进行分割，并将这些数据交给网络层，保证这些数据段有效到达对端。比如TCP传输控制协议、UDP用户数据协议。

- 网络层：控制子网的运行：逻辑编址、分组传输、路由选择，比如 IP、IPV6、SLIP 等等。路由器工作在网络层。

- 数据链路层：物理寻址，同时将原始比特流转变为逻辑传输路线，比如 XTP 压缩传输协议、PPTP 点对点隧道协议等等。交换机工作在数据链路层。

- 物理层：机械、电子、定时接口通信信道上的原始比特流传输，比如 IEEE802.2 等等，会尽可能屏蔽传输媒介和通信手段的差异。

下面这张图详细将OSI七层模型详细地进行了总结（图片来源于网络），供同学们参考。

!OSI

传输控制协议 TCP #

传输控制协议-TCP：TCP是面向连接的、可靠的、基于字节流的传输层通信协议，它将应用层的数据流分割成报文段并发送给目标节点的TCP层。数据包都有序号，对方收到则发送ACK确认，未收到则重传。TCP使用奇偶校验和来检验数据在传输过程中是否有误，在发送和接收时都要计算校验和。

 TCP/IP四层网络模型 

TCP/IP协议被组织成四个概念层，其中有三层对应于OSI参考模型中的相应层。TCP/IP协议族并不包含物理层和数据链路层，因此它不能独立完成整个计算机网络系统的功能，必须与许多其他的协议协同工作。 TCP/IP分层模型的四个协议层分别完成以下的功能：

- 网络接口层：网络接口层包括用于协作IP数据在已有网络介质上传输的协议，如ARP，RARP。
- 网际层：网际层对应OSI七层参考模型的网络层。负责数据的包装、寻址和路由。同时还包含网际控制报文协议(Internet Control Message Protocol,ICMP)用来提供网络诊断信息(常见的Ping命令)。
- 传输层对应OSI七层参考模型的传输层，它提供两种端到端的通信服务。其中TCP协议(Transmission Control Protocol)提供可靠的数据流运输服务，UDP协议(User Datagram Protocol)提供不可靠的用户数据报服务。
- 应用层对应OSI七层参考模型的应用层和表示层。

 TCP协议的三次握手🤝(重点) 

第一次握手：客户端发送SYN包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到SYN包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态； 

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去。

三次握手流程图如下：

!三次握手流程图

 为什么是三次握手？（不能是两次握手吗？） 

答：第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。客户端发送的连接请求可能会在网络中滞留，可能导致很长一段时间后才能收到服务器发回的ACK信息。若超过客户端的超时重传时间后，客户端就会重新请求连接。之前发送的滞留的连接请求最后还是会到达服务器，如果没有第三次握手，服务器就会打开两个连接。如果有第三次握手，客户端就会忽略服务器之后发送的对滞留连接请求的连接确认，服务器也就不会再次打开连接。

 首次握手存在什么安全隐患？ 

答：SYN超时机制可能导致SYN Flood攻击。因为服务器收到客户端的SYN，回复SYN-ACK时没有收到ACK确认，服务器会不断进行重试直至超时，Linux默认等待63秒才断开连接，攻击者可能利用此机制发动SYN洪水，不断建立连接后断开，造成SYN队列满，让正常连接无法得到处理。

SYN Flood防护措施：SYN队列满后，通过tcp_syncookies参数回发SYN Cookie，若是正常连接则客户端会发回SYN Cookie，直接建立连接，而非法连接则不会。

 建立连接后客户端出现故障怎么办？ 

答：TCP设有保活机制。在keep alive time即保活时间内，开启保活功能的一端将向对方发送保活探测报文，如果未收到响应则继续发送。当尝试次数达到保活探测数时若仍未收到响应则中断连接。

 TCP协议的四次挥手👋🏻(重点) 

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。

第一次挥手：客户端发送释放连接的报文FIN，用来关闭客户端到服务器的数据传送。

第二次挥手：服务器收到客户端发送的FIN，发回客户端确认报文ACK，此时ACK=1，确认序号为收到的序号+1。此时，TCP连接处于半关闭状态。即服务器进入CLOSE_WAIT状态。

第三次挥手：服务器不再需要连接时，发送释放连接报文FIN给客户端，此时FIN=1，ACK=1。关闭与客户端的数据传送，服务器进入LAST_ACK状态。

第四次挥手：客户端收到后发出确认，ACK=1，确认序号为收到序号+1，并进入TIME-WAIT状态，等待2MSL（最大报文存活时间）后释放连接。服务器端收到客户端的确认信息后立即释放连接。

 为什么是四次挥手？ 

答：因为全双工通信发送方和接收方都需要FIN报文和ACK报文。客户端发送了FIN释放连接报文后，服务器收到了这个报文，进入CLOSE-WAIT状态。这个状态是为了让服务器发送还未发送完成的数据，发送完毕后，服务器会发送FIN释放了连接报文。

 为什么还要等待2MSL后才释放连接？ 

答：

1. 确保有足够的时间让对方收到ACK包。如果服务器没收到客户端发送来的确认报文，就会重新发送释放连接报文，客户端等待2MSL就是为了处理这种情况的发生。

2. 可以避免新旧链接混淆。等待2MSL可以让该连接时间段内产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

 服务器出现大量CLOSE_WAIT的原因是什么？怎么办？ 

答：可能是对方关闭Socket连接，我方忙于读或写，没有及时关闭连接。解决方法：检查代码，特别是释放资源的代码；检查配置，特别是处理请求的线程配置。

 TCP如何保证可靠传输？ 

- 发送方给每个包进行编号，接收方对数据包进行排序，再把有序数据交付给应用层。 

- TCP会保持首部和数据的校验和，目的是检测数据在传输过程中的变化，如果检验和有差错，TCP将丢弃这个报文段且不确认收到此报文段。

- 发送方每发完一个报文段就停止发送，等待接收方确认。收到接收方的确认后再发下一个报文段；如果不能及时收到确认，将发送方重发这个报文段。

- 流量控制：当接收方来不及处理发送方的数据，就会提示发送方降低发送速率。TCP利用滑动窗口实现流量控制。

- 拥塞控制：当网络拥塞时，会减少数据的发送。

 TCP的滑动窗口 

TCP使用滑动窗口做流量控制与乱序重排。发送方和接收方各有一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接受窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。接收窗口只会对窗口内最后一个按序到达的字节进行确认。发送方得到一个字节的确认后，就知道这个字节之前的所有字节都已经被接收。

 TCP的拥塞控制 

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，导致网络拥塞程度更高。因此，当出现拥塞时，应当控制发送方的速率。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。TCP主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

 慢开始和拥塞避免 

慢开始让拥塞窗口大小为1，收到确认后，会将窗口大小翻倍（2,4,8...）慢开始有一个限制ssthresh，当拥塞窗口大小 >= ssthresh的一半时，会进入拥塞避免。

在拥塞避免中，ssthresh每次收到确认后不再是翻倍，而是+1。如果出现了超时，则ssthresh将设置为当前拥塞窗口的一半，然后重新执行慢开始。

 快重传和快恢复 

接收方会对最后一个收到的有序报文段进行确认。例如已经接收到M 1和M 2，此时收到M 4，应当发送对M 2的确认。发送端如果收到了三个重复的确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到3个M 2，则M 3丢失，立即重传M 3。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复：拥塞窗口大小设置为原来的一半，然后不再执行慢开始，直接进入拥塞避免。

用户数据报协议-UDP #

UDP即用户数据报协议，是一个无连接的简单的面向数据报的传输层协议。UDP面向非连接，不维护连接状态，支持同时向多个客户端传输相同的信息。由于其数据报头只有8个字节所以额外开销较小。吞吐量只受限于数据生成速率、传输速率以及机器性能。UDP会尽最大努力交付，但不保证可靠交付，无需维持复杂的链接状态表。它是面向报文的，不对应用程序提交的报文信息进行拆分或合并。

TCP和UDP的区别 #

它们的区别如下：

- TCP提供面向连接、可靠的数据传输服务；UDP提供无连接、最大努力的数据传输服务。
- TCP 主要提供完整性服务，UDP 主要提供及时性服务。
- UDP支持一对一，一对多，多对一，多对多；TCP只支持一对一。
- UDP不具备有序性，TCP可保证有序性。

超文本传输协议-HTTP #

HTTP（HyperText Transfer Protocol），即超文本传输协议。是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。它基于 TCP/IP 通信协议来传递数据（HTML 文件、图片文件、查询结果等）。

 输入URL后会发生什么(重点) 

1. DNS解析：浏览器会根据URL逐层查询DNS缓存，解析URL的域名所对应的IP地址。

   > 注：DNS缓存由近到远依次是：浏览器缓存->系统缓存->路由器缓存->IPS服务器缓存->根域名服务器缓存->顶级域名服务器缓存。

2. 建立TCP连接：找到IP地址后，会根据IP地址和对应的端口（默认80），和服务器通过三次握手建立TCP连接。

3. 发送HTTP请求：浏览器会给服务器发送读取文件的HTTP请求。

4. 服务器响应：服务器对浏览器请求作出响应，并把带有HTML文本的HTTP响应报文发送给浏览器。

5. 浏览器解析渲染页面：浏览器收到HTML并在视窗内进行渲染。

6. 连接结束：浏览器和服务器通过四次挥手释放TCP连接。

> 第5步和第6步没有先后顺序。

 常见的HTTP状态码 

- 1xx: 提示信息，表示请求已被接收，继续处理。
- 2xx: 成功，表示请求已被成功接收，理解，接受。
- 3xx: 重定向，要完成请求必须进行进一步操作。
- 4xx: 客户端错误，请求有格式错误或请求无法实现。
- 5xx: 服务端错误，服务器未能响应合法请求。

| 状态码                    | 解释                                                         |
| ------------------------- | ------------------------------------------------------------ |
| 200 OK                    | 正常返回                                                     |
| 400 Bad Request           | 客户端请求有格式错误，不能被服务器所理解                     |
| 401 Unauthorized          | 请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用 |
| 403 Forbidden             | 服务器收到请求，但拒绝提供服务                               |
| 404 Not Found             | 请求资源不存在（输入错误的URL）                              |
| 500 Internal Server Error | 服务器内部错误                                               |
| 503 Server Unavailable    | 服务器当前不能处理客户端请求，一段时间后可能恢复正常         |

 GET请求和POST请求的区别(基础但很重要) 

- HTTP报文层面：GET将请求信息放在URL，浏览器会对URL长度进行限制；POST将信息放在报文体中，大小无限制。
- 数据库层面：GET作为查询请求，每次执行得到的结果都相同，且不会修改数据，因此符合幂等性和安全性；POST会往数据库中提交数据，不符合幂等性和安全性。
- 其他层面：GET请求可以被浏览器记录，可以被缓存和存储，POST请求不行。

 Cookie和Session 

 Cookie 

Cookie是由服务器发送给客户端的特殊信息，以文本的形式存放在客户端。客户端再次请求时，会把Cookie回发。服务器接收到后，会解析Cookie生成与客户端相对应的内容。

 Session 

Session是服务端的机制，在服务端保存的信息。解析客户端请求并操作session id，并按需保存状态信息。

 Cookie和Session的区别 

- 数据存放位置不同：Cookie数据存放在客户的浏览器上，Session数据放在服务器上。
- 安全程度不同：Cookie并不安全，攻击者可以分析存放在本地的Cookie，可能会带来安全问题。Session是相对安全的。
- 性能差别：Session会在其生命周期内保存在服务器上。当访问量增加，会占用服务器的性能，可使用Cookie减轻服务器性能开销。
- 数据存储大小不同：单个Cookie保存的数据不能超过4KB，许多浏览器都限制一个站点最多保存20个Cookie。而Session则存储于服务端，不受浏览器限制。

HTTPS #

HTTPS（全称：Hyper Text Transfer Protocol over SecureSocket Layer），它是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。HTTPS 在HTTP 的基础上加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

 什么是SSL？ 

SSL（Security Sockets Layer），即安全套阶层，它是为网络通信提供安全及数据完整性的一种安全协议，SSL3.0后改名为TLS，采用身份验证和数据加密来保证网络通信的安全和数据的完整性。

 SSL 加密方式 

- 对称加密：加密和解密都使用同一个密钥。
- 非对称加密：加密使用的密钥和解密使用的密钥是不相同的。（公钥和私钥）
- 哈希算法：将任意长度的信息转换为固定长度的值，算法不可逆。
- 数字签名：证明某个消息或者文件是某人发出/认同的。

 HTTPS数据传输流程 

1. 浏览器将支持的加密算法信息发送给服务器。
2. 服务器选择一种浏览器支持的算法，以证书的形式回发给浏览器。
3. 浏览器检查证书的合法性，并用证书中的公钥对随机生成的消息进行加密。
4. 服务器用自己的私钥解密消息，确定密码，验证哈希，并加密响应消息回发给浏览器。
5. 浏览器解密响应消息，如果跟之前发过去的哈希值一致，那么之后都使用之前生成的随机密码加密。

 HTTPS的加密过程 

1. 服务器拥有CA证书的公钥和私钥；
2. 浏览器向服务器发送请求，服务器将证书公钥传输给浏览器；
3. 浏览器验证证书有效后，随机生成一个密钥，再用公钥加密后传给服务器；
4. 服务器收到后用私钥解密可以得到这个密钥；
5. 这样浏览器和服务器双方都有密钥，之后双方所有的数据都通过密钥加密解密就行。

有了CA证书，可以避免中间人攻击，浏览器可以确保收到的公钥一定是请求网站发过来的。

HTTP和HTTPS的区别 #

- HTTP需要到CA申请证书，HTTP不需要。
- HTTPS密文传输，HTTP明文传输。
- 连接方式不同，HTTPS默认使用443端口，HTTP使用80端口。
- HTTPS = HTTP + 加密 + 认证 + 完整性保护，较HTTP安全。

Socket 套接字 #

Socket是对TCP/IP协议的抽象，是操作系统对外开放的接口，它封装了一系列网络操作的API。

Socket的通信流程如下图所示：

!socket

Socket面试中问得较少，但也可能被问到，建议同学们亲自动手编写一个demo来实现服务器和客户端的socket通信。

本文主要讲解计算机网络知识点及面试题。

计算机网络知识点及面试题详解

Spring概述 #

 什么是Spring？ 

>  Spring 是一款开源的轻量级 Java 开发框架，旨在提高开发人员的开发效率以及系统的可维护性。

 你们项目为什么使用Spring框架？ 

这个问题我们直接回答其优点即可。

- 轻量：Spring是轻量级框架，基本版本大约只有2MB。
- 控制反转（IoC）：Spring通过控制反转实现了松散耦合，使其具备高可维护性和拓展性。
- 面向切面编程（AOP）：Spring支持面向切面编程，能够很方便地进行日志记录，数据库访问等。
- 容器：Spring包含并负责管理应用中对象的生命周期和配置，无需手动干预。
- 事务管理：Spring提供一个持续的事务管理接口，可以扩展到上至本地事务下至全局事务（JTA）。
- 异常处理：Spring 提供方便的API把具体技术相关的异常（比如由JDBC，Hibernate or JDO抛出的）转化为一致的unchecked 异常。

 Spring的组成部分 

!Spring组成

重要模块如下：

- Spring Core：核心类库，提供IoC服务
- Spring Context：提供框架式的Bean访问方式，以及企业级功能（JNDI、定时任务等）；
- Spring Aspects：提供AspectJ 集成支持
- Spring AOP：提供面向切面编程实现
- Spring DAO：对JDBC的抽象，简化了数据访问异常的处理；
- Spring ORM：对现有的ORM框架的支持；
- Spring Web：提供了基本的面向Web的综合特性，如：Web基本功能，WebSockets等。
- Spring MVC：提供面向Web应用的Model-View-Controller实现。
- Spring Test：集成测试模块。（Spring团队提倡测试驱动开发，即TDD）

依赖注入(DI) #

 什么是依赖注入？ 

依赖注入，即Dependency Inversion，全称是“依赖注入到容器”，通俗地讲，容器是某个对象，如果把某个类放入这个容器中，通过“依赖注入”可以解析出这个类的实例。

 依赖注入的方式有哪些？ 

依赖注入的方式：

- 构造器注入：将被依赖对象通过构造函数的参数注入给依赖对象，并且在初始化对象的时候注入。

  - 优点： 对象初始化完成后便可获得可使用的对象。

  - 缺点： 当需要注入的对象很多时，构造器参数列表会变得很长，不够灵活。若有多种注入方式，每种方式只需注入指定几个依赖，那么就需要提供多个重载的构造函数，使得代码难以维护。

- setter方法注入：IoC Service Provider通过调用成员变量提供的setter函数将被依赖对象注入给依赖类。

  - 优点： 灵活，可以有选择性地注入需要的对象。

  - 缺点： 由于依赖对象初始化完成后尚未注入被依赖对象，故还不能使用。

- 接口注入：依赖类必须要实现指定的接口，然后实现该接口中的一个函数，该函数就是用于依赖注入，该函数的参数就是要注入的对象。

  - 优点：接口注入中，接口的名字、函数的名字都不重要，只要保证函数的参数是要注入的对象类型即可。

  - 缺点： 侵入性太强，破坏系统的封装性，不建议使用。

还有一种注入方式是注解注入，即使用@Autowired进行注入。严格地说，它不是一种新的注入方式，注解注入本质上还是Setter注入或构造函数注入。

控制反转(IoC) #

 什么是IoC 

IoC（Inversion of Control）控制反转，是Spring Core最核心的部分，它是一种设计思想，不是具体的技术实现。IoC的思想就是将原本需要手动创建的对象交由Spring框架进行管理，Spring会根据容器的配置文件去创建实例和管理实例之间的依赖关系，对象与对象之间松散耦合，有利于功能的复用。简单来说，IoC让对象创建不用去new了，可以由Spring自动生产，并配合Java的反射机制，根据 配置文件在运行的时候动态去创建对象及管理对象，并调用对象方法。

在没有IoC之前，项目中的一个类可能依赖于很多其他不同的类，如果我们需要实例化这个类，我们需要搞清楚所有依赖类的构造函数，并逐一实例化，在添加或者修改类结构时，项目几乎无法维护。有了IoC之后，只需要配置好，并在需要的地方进行引用，这大大增加了可维护性。

 依赖倒置原则、IoC、DI、IoC容器的关系 

> 依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

关系如图所示：

!关系图

Spring Bean #

 什么是Bean？ 

Spring bean是指被Spring IoC容器管理的对象。Bean是由Spring IoC容器进行实例化、组装和管理的对象。它是在程序运行时，通过反射机制生成的。

在使用时，我们需要编写配置文件告诉IoC容器帮助我们管理哪些对象，可以通过XML文件、注解或Java配置类进行配置。

 BeanFactory 

BeanFactory是Spring框架最底层的接口，它提供了IoC的配置机制，包含Bean的各种定义，便于实例化Bean。在实例化时，BeanFactory可用于建立Bean之间的依赖关系。

 ApplicationContext 

ApplicationContext，即应用上下文，继承自BeanFactory接口，它是Spring的一个更高级容器，提供了更丰富的功能：

- 国际化（MessageSource）
- 访问资源，如URL和文件（ResourceLoader）
- 载入多个（有继承关系）上下文 ，使得每一个上下文都专注于一个特定的层次，比如应用的web层
- 消息发送、响应机制（ApplicationEventPublisher）
- AOP

 BeanFactory和ApplicationContext的区别 

- 加载方式不同：BeanFactory采用的是延迟加载（懒加载）的方式来注入Bean的。在启动的时候不会实例化Bean，只有在使用到某个Bean，即调用getBean()时才会对该Bean进行实例化。ApplicationContext在启动时就会将所有Bean进行实例化。不过当Bean配置了lazy-init=true时，ApplicationContext也会延迟对该Bean的加载。

- BeanFactory是Spring框架的基础设施，面向Spring，而ApplicationContext面向使用Spring框架的开发者，相比BeanFactory提供了更多面向实际应用的功能，几乎所有场合都能够直接使用ApplicationContext，而不是使用底层的BeanFactory。

 Bean的作用域 

Bean的作用域：

- singleton：唯一的bean实例，与单例模式相同，Spring中的bean默认都是单例的。
- prototype：每次请求都会创建一个新的bean实例。
- request：为每个http请求都创建一个新的bean，该bean仅在当前http request内有效
- session：每次来自新session的请求都创建一个新的bean，该bean仅在当前session内有效。
- global-session ： 全局 session 作用域，仅仅在基于 portlet 的 web 应用中才有意义，Spring5 已经没有了。

 Bean的生命周期 

Bean生命周期：

创建bean

1. 实例化Bean：对于BeanFactory容器，当客户向容器请求一个尚未初始化的bean时，或初始化bean的时候需要注入另一个尚未初始化的依赖时，容器就会调用createBean进行实例化。对于ApplicationContext容器，当容器启动结束后，通过获取BeanDefinition对象中的信息，实例化所有的bean。
2. 设置对象属性（依赖注入）：实例化后的对象被封装在BeanWrapper对象中，Spring根据BeanDefinition中的信息以及通过BeanWrapper提供的设置属性的接口完成依赖注入。
3. 处理Aware接口：在这一步，Spring会检测对象是否实现了xxxAware接口，并将相关的xxxAware实例注入给Bean：
   - 如果这个Bean已经实现了BeanNameAware接口，则调用它所实现的setBeanName(String beanId)方法，此处传递的是Spring配置文件中Bean的id值。
   - 如果这个Bean已经实现了BeanFactoryAware接口，会调用它所实现的setBeanFactory()方法，传递的是BeanFactory自身。
   - 如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传递的是ApplicationContext；
4. BeanPostProcessor：如果想对Bean进行一些自定义的处理，可以让Bean实现BeanPostProcessor接口，这样做会调用postProcessBeforeInitialization(Object obj, String s)方法。
5. InitializingBean与init-method：如果Bean在Spring配置文件中配置了init-method属性，则会自动调用其配置的初始化方法。
6. 如果这个Bean实现了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法。另外，由于这个方法是在Bean初始化结束时调用的，所以可以被应用于内存或缓存技术。

> 以上几个步骤执行完成后，Bean就已经被正确创建了，之后就可以使用这个Bean了。

销毁bean

7. DisposableBean：若Bean实现了DisposableBean这个接口，会调用其实现的destroy()方法。
8. destroy-method：若配置了destroy-method属性，则会调用其配置的销毁方法。

最后我通过一张图来总结Bean的生命周期。

!Bean的生命周期

 @Component和@Bean的区别 

- @Component作用于类，而@Bean作用于方法
- @Component会自动扫描路径来自动装配Bean到Spring IoC中，也可以通过@ComponentScan自定义扫描路径。@Bean表示方法产生一个由Spring管理的bean。
- @Bean 比 @Component 的自定义性更强，许多地方我们只能通过 @Bean 来对bean进行注册。比如当我们引用第三方库中的类需要装配到 Spring容器时，则只能通过 @Bean来实现。

Spring AOP #

 谈谈你对AOP的理解 

AOP（Aspect-Oriented Programming）面向切面编程，它能够将那些与业务无关，却为业务模块所共同调用的通用功能（例如事务处理、日志管理、权限控制等）封装起来，减少系统中的重复代码，降低模块间的耦合度，提高项目的拓展性和可维护性。

它的基本思想如下：AOP注重关注点分离，即不同的问题交给不同的部分去解决，目的是为了将业务功能的关注点和通用化功能的关注点进行分离。这些通用化功能（例如：事务处理、日志管理...）的代码实现就是所谓的切面(Aspect)。业务功能代码和切面代码分开后，架构将变得高内聚，低耦合。最后，切面需要最终被合并到业务中，确保功能的完整性，这就是织入（Weave）。

 AOP的三种织入方式 

- 编译时织入：需要特殊的Java编译器，如AspectJ。
- 类加载时织入：需要特殊的Java编译器，如AspectJ何AspectWerkz。
- 运行时织入：Spring AOP采用的方式，通过动态代理的方式，实现简单。

 AOP中的重要概念 

AOP，面向切面编程，即Aspect Oriented Programming。

- Aspect：切面，类似于Java中的类声明，是对系统中横跨多个类的关注点进行模块化封装
- Joinpoint：连接点，程序执行过程中的一个“点”，例如：方法的执行或异常的处理。在Spring AOP中，一个连接点总是代表一个方法的执行。
- Pointcut：切入点，即一组连接点的集合；
- Advice：通知，定义了将会织入到 Joinpoint 的具体逻辑，通过@Before、@After、@Around等注解来区别在JointPoint之前、之后等位置执行代码
- Weaving：织入，织入指的是将Advice连接到Pointcut指定的Joinpoint处的过程
- Interceptor：拦截器，是一种实现Advice（通知）的方式；
- Target：目标对象，即符合切入点所指定的条件被织入Advice的对象。

 Advice的种类 

- 前置通知（Before）
- 后置通知（AfterReturning）
- 异常通知（AfterThrowing）
- 最终通知（After）
- 环绕通知（Around）

 AOP的实现 

前置知识：设计模式-代理模式，可查看我的这篇文章：https://www.yeliheng.com/articles/dc912a27

在Java中，AOP有两种基于动态代理的实现方式，分别是JDK Proxy和cglib。具体使用哪种方式生成，由AopProxyFactory根据AdvisedSupport对象的配置来决定。默认策略是：如果目标类是接口，则采用JDK Proxy来实现，否则使用cglib来生成代理。

JDK Proxy的核心是InvocationHandler接口和Proxy类，通过Java内部的反射机制实现。

cglib是通过修改字节码来实现代理的，底层基于ASM框架（ASM是一种字节码操作框架）。它以继承的方式动态生成目标类的代理，因此，如果某个类被final关键字修饰，则无法使用cglib来做动态代理。

反射机制在生成类的过程中比较高效，ASM在生成类之后的执行过程中比较高效。

 Spring中的代理模式的实现 

- 真实实现类的逻辑包含在getBean()方法中。
- getBean方法返回的实际上是Proxy的实例。
- Proxy实例是Spring采用JDK Proxy或cglib动态生成的。

注：getBean()方法用于查找或实例化容器中的Bean，这样是为什么Spring AOP只能作用于Spring容器中的Bean的原因。对于不是使用IoC容器管理的对象，Spring AOP是无能为力的。

 Spring AOP的应用 

请查看我的这篇文章：Spring AOP的最佳实践：在你的系统中记录用户的操作日志

Spring 事务 #

 Spring管理事务的方式 

- 编程式事务管理：在代码中通过编码的方式实现事务，例如通过TransactionTemplate或TransactionManager手动管理事务，这种方式不推荐在项目中使用，实现复杂，会使得代码难以维护。
- 声明式事务管理：此方式意味着你可以将事务管理和业务代码分离，只需要使用注解或在Xml配置文件中进行配置。在项目中经常基于AOP实现，使用@Transactional进行事务管理。

 事务三要素是什么？ 

数据源：表示具体的事务性资源，是事务的真正处理者，如MySQL等。

事务管理器：像一个大管家，从整体上管理事务的处理过程，如打开、提交、回滚等。

事务应用和属性配置：像一个标识符，表明哪些方法要参与事务，如何参与事务，以及一些相关属性如隔离级别、超时时间等。

 Spring 事务中有哪几种的事务传播行为？ 

>  事务传播行为是为了解决业务层方法之间互相调用的事务问题。当事务方法被另一个事务方法调用时，必须指定事务应该如何传播。例如：方法可能继续在现有事务中运行，也可能开启一个新事务，并在自己的事务中运行。

Spring事务定义了以下7种传播行为：

1. PROPAGATION_REQUIRED：默认的Spring事务传播级别，若当前存在事务，则加入该事务，若不存在事务，则新建一个事务。

2. PAOPAGATION_REQUIRE_NEW：若当前没有事务，则新建一个事务。若当前存在事务，则新建一个事务，新老事务相互独立。外部事务抛出异常回滚不会影响内部事务的正常提交。

3. PROPAGATION_NESTED：如果当前存在事务，则嵌套在当前事务中执行。如果当前没有事务，则新建一个事务，类似于PAOPAGATION_REQUIRE_NEW。

4. PROPAGATION_SUPPORTS：支持当前事务，若当前不存在事务，以非事务的方式执行。

5. PROPAGATION_NOT_SUPPORTED：以非事务的方式执行，若当前存在事务，则把当前事务挂起。

6. PROPAGATION_MANDATORY：强制事务执行，若当前不存在事务，则抛出异常。

7. PROPAGATION_NEVER：以非事务的方式执行，如果当前存在事务，则抛出异常。

 说说Spring事务的隔离级别 

- ISOLATION_DEFAULT：使用数据库默认的隔离级别。MySQL 默认采用的 REPEATABLE_READ 隔离级别，Oracle默认采用的READ_COMMITTED隔离级别。

- ISOLATION_READ_UNCOMMITTED：这是事务最低的隔离级别，它允许读取该事务尚未提交的数据变更。此隔离级别可能会产生脏读、幻读或不可重复读。
- ISOLATION_READ_COMMITTED：保证一个事务修改的数据提交后才能够被另外一个事务读取。此隔离级别可以阻止脏读，但是幻读或不可重复读仍有可能发生。
- ISOLATION_REPEATABLE_READ：它除了保证一个事务不能读取另外一个事务未提交的数据外，还保证对同一字段多次读取结果都是一致的，除非数据是被自身事务所修改。此隔离级别可以阻止脏读和不可重复读，但幻读仍有可能发生。
- ISOLATION_SERIALIZABLE：最高的隔离级别，完全服从 ACID 的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能，开销巨大，使用场景较少。

 事务注解的本质是什么？ 

@Transactional这个注解仅仅是一些（和事务相关的）元数据，在运行时被事务基础设施读取消费，并使用这些元数据来配置bean的事务行为。 大致来说具有两方面功能：

- 表明该方法要参与事务。
- 配置相关属性来定制事务的参与方式和运行行为。

声明式事务主要得益于Spring AOP。使用一个事务拦截器，在方法调用的前后/周围进行事务性通知（Advice），来驱动事务完成。@Transactional注解既可以标注在类上，也可以标注在方法上。当在类上时，默认应用到类里的所有方法。如果此时方法上也标注了，则方法上的优先级高，另外注意方法必须是public的。

本文整理了Spring框架原理及部分常见面试题，方便同学们复习。

Spring框架原理及面试题详解

本文整理了一些面试常考的Java基础知识点，方便同学们复习。

Java基础知识以及面试题总结

Java堆 #

> Java 堆是垃圾收集器管理的主要区域，因此也被称作GC 堆（Garbage Collected Heap）。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代：再细致一点有：Eden 空间、From Survivor、To Survivor 空间等。进一步划分的目的是更好地回收内存，或者更快地分配内存。

下面我们来具体介绍Java堆中的分代。

 年轻代 

年轻代主要分为两个区，分别是Eden区和2个Survivor区。年轻代存在的意义是让GC尽可能快速地收集生命周期较短的对象。年轻代内存示意图如下：

> Tip: Eden即伊甸园，传说此处是人类的起源之地，故对象刚被创建出来被放入Eden区。

!年轻代

从图中可以看出年轻代内存分为一块Eden区和两块较小的Survivor空间，分别是8:1:1的比例。当进行垃圾回收时，将Eden和Survivor中存活的对象一次性复制到另一块Survivor空间中，最后清理Eden和用掉的Survivor空间。当Survivor空间都不够用时，则需要老年代进行分配收集。

大部分情况下，对象都会先在Eden区进行分配（除非如Eden区已满），在一次年轻代垃圾回收后，如果对象还存活，则对象会从Eden区进入 s0 或者 s1区域中，并且对象的年龄加 1，当它的年龄增长到阈值时（默认为大于 15 岁），就会被晋升到老年代中，可以通过参数 -XX:MaxTenuringThreshold 来设置该阈值。

常用的调优参数：

- -XX:SurvivorRatio：Eden和Survivor的比值，默认8:1。
- -XX:NewRatio：老年代和年轻代内存大小的比例。
- -XX:MaxTenuringThreshold：对象从年轻代晋升到老年代经过GC次数的最大阈值。

 老年代 

老年代存放生命周期较长的对象。以下对象会进入到老年代中：

- 经历一定Minor次数依然存活的对象，即默认年龄大于15（Minor我们下文会进行介绍）
- Survivor区中存放不下的对象
- 新生成的大对象

判断一个对象是否可被回收的方法 #

 引用计数法 

- 通过判断对象的引用次数来决定对象是否可被回收。
- 每个对象实例都有一个引用计数器，被引用则+1，完成引用则-1。
- 任何引用计数为0的对象实例可以被当作垃圾收集。

优点：执行效率高，程序执行受影响较小。

缺点：无法检测出循环引用的情况，容易导致内存泄露。循环引用例子如下：

`java
package com.yeliheng.gc;

public class ReferenceCountingGC {
    Object ref = null;
    public static void main(String[] args) {
        ReferenceCountingGC o1 = new ReferenceCountingGC();
        ReferenceCountingGC o2 = new ReferenceCountingGC();
        o1.ref = o2;
        o2.ref = o1;
    }
}
`

o1和o2两个对象互相引用对方，除此之外没有其他任何引用。但由于彼此之间循环引用，导致它们的引用计数器永远不会为0，所以使用引用计数法无法让GC对其进行回收。

 可达性分析算法 

通过判断对象的引用链是否可达来决定对象是否可以被回收。如下图所示，可达性分析算法以GC Root为起始点进行搜索，可达的对象都是存活的，不可达的对象可被回收。

!可达性分析

 可作为GC Root的对象 

- 虚拟机栈中引用的对象（栈帧中的本地变量表）。
- 方法区中的常量引用的对象。
- 方法区中的类静态属性引用的对象。
- 本地方法栈中JNI即Native方法的引用对象。
- 活跃线程的引用对象。

垃圾回收算法 #

 标记-清除算法(Mark and Sweep) 

- 标记：从根集合进行扫描，对存活的对象进行标记。
- 清除：对堆内存从头到尾进行线性遍历，回收不可达对象内存。

它是最基础的收集算法，后续的算法都是对其不足进行改进得到。

缺点：会产生大量内存碎片，导致无法给大对象分配内存。

 复制算法(Copying) 

复制算法将内存分为对象面和空闲面，对象在对象面上创建，把存活的对象从对象面复制到空闲面，再将对象面上所有的内存清除。此算法解决了碎片化的问题，按顺序分配内存，简单高效，适用于对象存活率低的场景。

!复制算法

 标记-整理算法(Compacting) 

标记整理算法会标记出所有存活的对象，然后让所有存活的对象向一端移动，并清理掉末端边界以外的内存。该算法做不会产生内存碎片，并且无需设置两块内存互换，适用于存活率极高的场景。但其需要移动大量对象，处理效率较低。

 分代收集算法（Generational Collector） 

按照对象的生命周期划分不同的区域，并采用不同的垃圾分类算法。可以理解成上述算法的综合。新生代对象存活率低，适合采用复制算法；老年代存活率高，复制大量对象成本较高，且无额外空间进行分配担保，所以一般采用标记-清除算法或标记-整理算法。

分代收集算法中GC的分类如下：

 GC分类 

- Minor GC：回收新生代，因为新生代对象存活时间很短，因此Minor GC会频繁执行，执行的速度一般也会比较快。
- Full GC：回收老年代和新生代，老年代对象存活时间长，因此Full GC很少执行，执行速度会比Minor GC慢得多。
- Major GC：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集，即Full GC。

 触发Full GC的条件 

- 调用System.gc()：只是建议虚拟机执行Full GC，虚拟机不一定会真正去执行。

- 老年代空间不足：大对象直接进入老年代、长期存活的对象进入老年代，导致老年代空间不足时，会触发Full GC。解决方法：避免创建过大的对象或者增大新生代晋升老年代的年龄。
- JDK1.7及之前永久代空间不足：永久代存放的是一些类信息、常量和静态变量等数据，当系统中加载的类、反射的类和调用方法较多时，永久代空间不足就会触发Full GC。所以JDK1.8用元空间取代永久代可以降低Full GC的频率，减少GC负担。
- 空间分配担保失败：使用复制算法的Minor GC需要老年代的内存空间作担保，如果担保失败会执行一次Full GC。
- Concurrent Mode Failure：执行CMS GC的过程中同时有对象要放入老年代，而此时老年代空间不足，便会报Concurrent Mode Failure 错误，并触发Full GC。

 空间分配担保 

>  空间分配担保是为了确保在 Minor GC 之前老年代本身还有容纳新生代所有对象的剩余空间。

在发生Minor GC之前，虚拟机先检查老年代最大可用的连续空间否大于新生代所有对象总空间，如果大于，那Minor GC可以确认是安全的。如果不大于，虚拟机会查看HandlePromotionFailure的值是否允许担保失败发生，如果允许那么就会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC；如果小于，或者HandlePromotionFailure的值不允许冒险，那么就要进行一次Full GC。

 Stop-the-world 

Stop-the-world指JVM由于要执行GC而停止了应用程序的执行，它在任何一种GC算法中都会发生。多数GC优化是通过减少Stop-the-world发生的时间来提高程序性能。

 Safepoint 

Safepoint即垃圾收集器中的安全点，用于分析过程中对象引用关系不会发生变化的点。一般出现在方法调用、循环跳转和异常跳转等位置。安全点的数量选取要适中，选取太少会让GC等待太久，选取太多会增加程序运行负荷。

常见的垃圾收集器 #

前置知识：JVM运行模式。

JVM运行模式有以下两种：

- Server：Server模式采用重量级JVM，优化更多，启动慢但稳定后效率高。
- Client：Client模式采用轻量级JVM，启动的速度快。

---

我们先来了解一下新生代垃圾收集器。

 Serial收集器 

用于新生代垃圾回收，采用复制算法，单线程收集，必须暂停所有工作线程。由于没有线程交互的开销，简单高效，是Client模式下默认的新生代垃圾收集器。

> 参数：-XX:+UseSerialGC

 ParNew收集器 

用于新生代垃圾回收，采用复制算法，多线程收集，其他特点与Serial收集器基本相同。ParNew收集器在单核CPU的执行效率不如Serial收集器，因为存在线程交互带来的开销，其在多核心CPU上执行才有优势。

> 参数：-XX:+UseParNewGC

 Parallel Scavenge收集器 

用于新生代垃圾回收，采用复制算法，也是多线程收集。Parallel Scavenge收集器更注重系统的吞吐量，ParNew收集器更注重减少用户线程停顿时间。Parallel Scavenge是Server模式下默认的新生代垃圾收集器。

> 参数：-XX:+UseParallelGC

> 吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

---

接下来是老年代垃圾收集器。

 Serial Old收集器 

Serial Old用于老年代垃圾回收，采用标记-整理算法。它是Serial收集器的老年代版本，除了采用的算法不同，其余特点与Serial收集器基本相同。Serial Old收集器是Client模式下默认的老年代垃圾收集器。在Parallel Old收集器诞生前，它与Parallel Scavenge收集器搭配使用。在CMS收集器发生Concurrent Mode Failure时，也会使用Serial Old收集器。

> 参数：-XX:+UseSerialOldGC

 Parallel Old收集器 

Parallel Old收集器用于老年代垃圾回收，采用标记-整理算法。Parallel Scavenge收集器的老年代版本，多线程，注重吞吐量。

> 参数：-XX:+UseParallelOldGC

 CMS收集器 

CMS（Concurrent Mark Sweep）收集器用于老年代垃圾回收，采用标记-清除算法，收集器线程可以和用户线程并发工作。CMS适合使用在对用户体验要求较高以及JVM中存在较多存活时间较长的对象的场景。它的垃圾回收过程分为以下六步：

1. 初始标记：stop-the-world仅标记与GC Roots直接关联的对象，速度很快。
2. 并发标记：进行GC Roots追溯标记，它在整个回收过程中耗时最长。由于并发标记的线程与应用程序的线程并发执行，所以用户不会感到停顿。
3. 并发预清理：并发预清理会查找执行并发标记阶段从新生代晋升到老年代的对象。
4. 重新标记：会暂停虚拟机，扫描CMS堆中的剩余对象，相对较慢。
5. 并发清理：清理垃圾对象，程序不会停顿。
6. 并发重置：重置CMS收集器的数据结构，等待下一次垃圾回收。

这6个步骤中，初始标记和重新标记需要短暂地stop-the-world。

CMS收集器的缺点：

- 吞吐量低，降低停顿时间是以牺牲吞吐量为代价的，导致CPU利用率不够高。

- 无法处理浮动垃圾。浮动垃圾是在并发清除时，由于用户线程继续运行而产生的垃圾。这部分垃圾只能等到下一次GC才能进行回收，浮动垃圾存在需要预留一部分内存，如果预留的内存不够存放浮动垃圾，就会出现Concurrent Mode Failure，这时虚拟机将临时启用Serial Old 收集器来替代CMS收集器。

- 采用的是标记-清除算法，会存在内存碎片，所以可能导致没有足够大的连续空间来分配大对象，不得不提前触发一次Full GC。

 G1收集器 

G1收集器（Garbage First）采用多线程收集，且可以和用户线程并发进行。它既可回收新生代，也可回收老年代，采用的是复制+标记-整理算法，不会产生内存碎片。使用G1收集器可以实现可预测的停顿，它能够让使用者指定在一个长度为M 毫秒的时间片段内，消耗在GC上的时间不得超过N毫秒。

G1收集器将整个Java堆内存划分为多个大小相等的Region，新生代和老年代不再物理隔离。通过记录每个Region垃圾回收时间以及回收所获得的空间，维护一个优先列表，每次可根据允许收集的时间，优先回收价值最大的Region。而且每个Region中还有一个Remembered Set，用来记录该Region中对象的引用对象所在的Region，在做可达性分析的时候就可以避免全堆扫描。

G1收集器工作流程包含以下四个步骤：

- 初始标记：和CMS收集器类似。
- 并发标记：和CMS收集器类似。
- 最终标记：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，这阶段需要停顿线程。
- 筛选回收：会对各个Region中的回收价值和成本进行排序，根据用户所期望的GC停顿时间，来回收价值最大的一部分Region。

 补充 

JDK11中还有一种ZGC，它与 CMS 中的 ParNew 和 G1 类似，ZGC 也采用标记-复制算法。不过 ZGC 对该算法做了重大改进，可以实现非常低的线程停顿时间，它通过使用着色指针和读屏障来实现。感兴趣的同学可以自行查阅相关资料。

面试题 #

 Object的finalize()方法的作用是否与C++的析构函数作用相同？ 

答：与C++的析构函数不同，析构函数调用时间确定，而finalize()方法的调用时间是不确定的。

进阶：当对象进行可达性分析时发现没有和GC Roots相连接会判断是否使用了finalize()方法。如果对象覆盖了finalize()方法，并且没使用过这个方法，对象就会被放在F-Queue中，然后稍后由JVM创建一个低优先级的finalize线程去执行触发finalize()方法。由于finalize线程优先级比较低，所以finalize()方法执行随时可能被终止。finalize()方法是为对象创建最后一次重生的机会，如果在finalize()方法中对象又再次和GC Roots相连，就不会被垃圾回收器回收。

此处我们通过一个例子直观理解：

`java
package com.yeliheng.gc;

public class Finalization {
    public static Finalization finalization;

    @Override
    protected void finalize() throws Throwable {
        System.out.println("Finalized");
        finalization = this;
    }

    public static void main(String[] args) {
        Finalization f = new Finalization();
        //第一次打印
        System.out.println("1: " + f);
        //将f置为空
        f = null;
        System.gc();
        // 第二次打印
        System.out.println("2: " + f);
        //调用
        System.out.println(f.finalization);
    }
}

`

运行以上demo会得到如下输出：

`
1: com.yeliheng.gc.Finalization@29453f44
2: null
null
Finalized

Process finished with exit code 0
`

我们会发现，最后调用f.finalization时，finalization = this;的效果并没有显现出来。这就体现了finalize在gc调用时间上的不确定性。

由于finalize方法运行的不确定性较大，无法保证各对象的调用顺序，同时运行代价也是相当高昂的，故不建议在生产环境中使用这个方法！

 Java中的强引用，软引用，弱引用，虚引用了解吗？ 

强引用：是最普遍的引用，JVM宁愿抛出OutOfMemoryError终止程序也不会回收具有强应用的对象，通过将对象设置为null来弱化引用，可以使其被回收。强

`java
Object obj = new Object(); // 强引用
`

软引用：对象处在有用但非必须的状态，只有当内存空间不足时，GC会回收该引用的对象的内存，可以用来实现内存敏感的高速缓存，不用担心OutOfMemory的问题，而且内存一般也是充足的，引用的对象会一直存在方便复用，可以和引用队列联合使用。

`java
String str = new String(“abc”);
SoftReference<String> softRef = new SoftReference<String>(str);
`

弱引用：非必须的对象，比软引用更弱一些。无论内存是否充足，GC都会回收弱引用对象。另外由于GC线程优先级比较低，被及时回收的概率也不大。适用于引用偶尔被使用且不影响垃圾回收的对象，可以和引用队列联合使用。

`java
String str = new String(“abc”);
WeakReference<String> weakRef = new WeakReference <String>(str);
`

虚引用：不会决定对象的生命周期，任何时候都可能被垃圾收集器回收。主要作用是跟踪对象被垃圾收集器回收的活动，起哨兵作用。必须和引用队列ReferenceQueue联合使用。

`java
String str = new String(“abc”);
ReferenceQueue queue = new ReferenceQueue();
PhantomReference ref = new PhantomReference(str, queue);
`

引用的级别由高到低分别为：强引用 -> 软引用 -> 弱引用 -> 虚引用

下面我用一个表格总结引用：

| 引用类型 |  被垃圾回收时间  |      作用      |     生命周期      |
| :------: | :--------------: | :------------: | :---------------: |
|  强引用  |   从来不会回收   | 对象的一般状态 | JVM停止运行时终止 |
|  软引用  | 在内存不足时回收 |    对象缓存    |  内存不足时终止   |
|  弱引用  | 在垃圾回收时回收 |    对象缓存    |   gc运行后终止    |
|  虚引用  | 任何时候都有可能 |   标记、哨兵   |     无法确定      |

补充：Java中引用的类层次结构，如下图所示。

!类结构

引用队列：存储关联的且被GC的软引用，弱引用以及虚引用。用处只是为了提醒程序员非强引用型变量所引用的对象已经具有不可达性了，再也不能获得堆中的那个对象了。

 CMS收集器和G1收集器的区别 

- 使用范围不同：CMS收集器是老年代的收集器，可以配合新生代的Serial收集器和ParNew收集器一起使用；G1收集器收集范围是老年代和新生代，不需要结合其他收集器使用。
- stop-the-world时间不同：CMS收集器是以最小的停顿时间为目标的收集器；G1收集器可预测指定垃圾回收的停顿时间。
- CMS收集器产生的内存碎片比G1收集器多：CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片；G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。
- 垃圾回收过程不同：
  - CMS收集器：初始标记、并发标记、重新标记、并发清除；
  - G1收集器：初始标记、并发标记、最终标记、筛选回收；

GC垃圾回收是JVM的一个重要部分，掌握GC有利于调试排查各种内存溢出问题。当系统遇到性能瓶颈时，我们也许能够通过JVM内部的技术细节来解决棘手的问题。

JVM基础之GC垃圾回收机制详解

JVM内存模型是JVM中的一个重要知识点，掌握内存模型有助于了解Java内存分配机制以及后续的GC机制，在实际项目中能够对常见OOM错误进行排查。

!JVM内存模型

此处JVM内存模型与Java内存模型（JMM）是两个不同的概念。关于Java内存模型JMM的介绍，请前往我的这篇文章。

Java运行时数据区 #

从图中可以看出：

线程私有：程序计数器、虚拟机栈、本地方法栈

线程共享：堆、元空间

注：元空间（MetaSpace）是JDK1.8之后加入的。在JDK1.8之前，它是方法区。具体将在下文介绍。

接下来我们具体来看运行时数据区的内容。

 程序计数器 

程序计数器记录当前线程执行的位置，是唯一一个不会出现OutOfMemoryError的内存区域。它的生命周期：随着线程的创建而创建，随着线程的结束而死亡。

- 当前线程所执行的字节码行号指示器（物理上不存在，是逻辑上的）。
- 改变计数器的值来选取下一条需要执行的字节码指令。
- 和线程是一对一的关系即：线程私有。
- 对Java方法计数，如果是native方法则计数器值为undefined。
- 不会发生内存泄露（唯一一个不会出现OutOfMemoryError的内存区域）。

 虚拟机栈 

虚拟机栈由一个个栈帧(Stack Frame)组成，每个栈帧中包含局部变量表、操作数栈、动态链接、返回地址。虚拟机栈是线程私有的。局部变量表主要存放的就是基本数据类型和对象引用。虚拟机栈可能会出现StackOverflowError和OutOfMemoryError错误。它的生命周期与程序计数器相同：随着线程的创建而创建，随着线程的结束而死亡。

栈是JVM运行时数据区域的一个核心，除了一些native方法的调用是通过本地方法栈实现的，其他所有的Java方法调用都是通过栈配合实现的。

调用方法会有一个对应的栈帧被压入栈中，每一个方法调用结束后，会将栈帧弹出。

栈的结构示意图如下：

!栈

>  局部变量表： 主要存放基本数据类型（boolean、byte、char、short、int、float、long、double...）、对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。

> 操作数栈： 用于存放方法执行过程中产生的中间计算结果，它充当中转站的作用。另外，计算过程中产生的临时变量也会放在操作数栈中。

> 动态链接： 主要服务一个方法需要调用其他方法的场景。在 Java 源文件被编译成字节码文件时，所有的变量和方法引用都作为符号引用（Symbilic Reference）保存在 Class 文件的常量池里。当一个方法要调用其他方法，需要将常量池中指向方法的符号引用转化为其在内存地址中的直接引用。动态链接的作用就是为了将符号引用转换为调用方法的直接引用。

 本地方法栈 

本地方法栈与虚拟机栈类似，虚拟机栈为执行Java方法提供服务，本地方法栈为执行native本地方法提供服务。本地方法栈也是线程私有的。

本地方法在执行时也会在本地方法栈处创建一个栈帧，方法执行完毕后响应的栈帧会弹出栈释放内存空间。本地方法栈也会出现StackOverflowError和OutOfMemoryError错误。

 堆 

堆是虚拟机管理内存中最大的一块，它是线程的共享区域，随着虚拟机的启动而创建。堆是对象实例的分配区域，GC管理的主要区域。在垃圾回收时，堆会被划分为新生代和老年代，其中新生代又被划分为Eden、From Survivor、To Survivor、Old区域。此处我们将在GC机制的文章中详细进行分析。

 方法区 

用于存放已被加载的类信息、常量、静态变量等。JDK1.6之前方法区的实现是永久代，JDK1.8时方法区实现是元空间。

关于永久代和元空间我们将在下文进行介绍。

 运行时常量池 

运行时常量池的功能类似于传统的编程语言的符号表。在Class文件的常量池中，存放着用于保存编译时生成的字面量和符号引用。在类加载后，Class文件常量池会放在运行时常量池中。运行时常量池也是方法区的一部分，它受方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError。

 字符串常量池 

字符串常量池是JVM为了提升性能和减少内存消耗针对String类专门开辟的一块区域，主要是为了避免字符串的重复创建造成资源的浪费。在JDK1.7之前，字符串常量池存放在永久代，JDK1.7后字符串常量池和静态变量移动到Java堆中。JDK1.8永久代的实现变成元空间。

面试题 #

 为什么递归会导致StackOverFlowError？ 

答：递归过深会造成栈帧中被压入过多的栈而占用太多空间，导致栈空间过深，而线程请求栈的深度是有限的，当线程请求栈深度超过当前Java虚拟机的最大深度时，就会引发java.lang.StackOverFlowError异常。补充：当虚拟机栈过多则会引发java.lang.OutOfMemoryError异常。

 元空间(MetaSpace)和永久代(PermGen)的区别 

答：元空间使用本地内存，而永久代使用的是JVM内存。

> 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是直接内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。

 元空间替代永久代的优势 

答：

-  字符串常量池存在永久代中，容易出现性能问题和内存溢出。而元空间使用直接内存，只受到本机可用内存限制，溢出概率小。
- 由于类和方法的信息大小难以确定，元空间将根据运行时应用程序需求动态调整大小，而永久代不会，确定大小十分困难。
- 元空间有利于减轻GC负担，而永久代会为GC带来不必要的复杂性。当系统中加载的类、反射的类和调用方法较多时，永久代空间不足就会触发Full GC。用元空间可以降低Full GC频率，减少GC负担。
- 元空间方便与HotSpot和其他JVM如Jrockit进行集成。（Jrockit没有永久代）

  JVM内存模型中堆和栈的区别 

答：

- 管理方式：栈自动释放，堆需要通过GC来释放。
- 空间大小：栈比堆小。JVM管理的内存中，堆是最大的一块。
- 碎片相关：栈产生的内存碎片远小于堆。
- 分配方式：栈支持静态分配和动态分配，堆仅支持动态分配。
- 效率：栈的效率比堆高。

 JDK1.7为什么要将字符串常量池移动到堆中？ 

答：因为永久代的GC回收效率太低，只有当Full GC时才会执行。这就造成Java程序中有大量被创建的字符串等待被回收。将字符串移动到堆中，能够及时地回收字符串内存。

 不同JDK版本之间的intern()方法有什么区别？ 

- JDK1.6：当调用intern()方法时，如果字符串常量池中已经存在该字符串的对象，则直接返回池中该字符串的引用。否则将此字符串对象添加到字符串常量池中，并返回该字符串的引用。
- JDK1.6+：当调用intern()方法时，如果字符串常量池中已经存在该字符串的对象，则直接返回池中该字符串的引用（此处与JDK1.6相同）。否则，如果该字符串对象已经存在于Java堆中，则将堆中此对象的引用添加到字符串常量池中，并返回该引用；如果堆中不存在，则在池中创建该字符串并返回其引用。

JVM内存模型是JVM中的一个重要知识点，掌握内存模型有助于了解Java内存分配机制以及后续的GC机制，在实际项目中能够对常见OOM错误进行排查。

JVM基础之JVM内存模型详解

开始 #

本文我整理了一些JVM类加载器相关的面试高频知识点，方便同学们复习。

在详细了解JVM知识点之前，我们先引入以下基础的经典面试题：

 谈谈你对Java的理解 

- 平台无关性，一次编译到处运行。

- GC垃圾回收机制：Java无需像C++一样手动管理内存。

- Java的语言特性：泛型、反射、lambda表达式等。

- 面向对象：包括封装、继承、多态。

- Java自身类库如：集合、并发库、网络库以及IO流。

- 异常处理。

 Java 和 C++的区别 

- Java不提供指针直接访问内存，程序的内存更加安全。
- Java的类是单继承，而C++的类是多继承（Java的接口是可以多继承的）。
- Java有自动垃圾回收机制，无需手动释放内存。
- Java可实现平台无关性，一次编译，不同系统平台都能运行。

 Java平台无关性是如何实现的？ 

Java源码首先被编译成字节码，再由不同平台的JVM进行解析，Java语言在不同的平台上运行时不需要重新编译，Java虚拟机在执行字节码的时候会将字节码转换成具体平台上的机器指令。所以Java也是一种编译与解释并存的语言。它即具备编译型语言的特征，也具备解释型语言的特征。

引用维基百科的介绍：

> 为了改善编译语言的效率而发展出的即时编译技术，已经缩小了这两种语言间的差距。这种技术混合了编译语言与解释型语言的优点，它像编译语言一样，先把程序源代码编译成字节码。到执行期时，再将字节码直译，之后执行。Java与LLVM是这种技术的代表产物。

 为什么JVM不直接将源码解析成机器码？ 

- 准备工作：每次执行前都需要进行各种检查。
- 兼容性：这样做使得其他语言也能够按照JVM的标准解析成字节码。

 JVM的主要组成部分 

- Class Loader：依据特定格式，加载class文件到内存。
- Execution Engine：对命令进行解析。
- Native Interface：融合不同开发语言的原生库为Java所用。
- Runtime Data Area：JVM内存空间结构模型。

前置知识-反射 #

 谈谈什么是反射？ 

Java反射机制是在运行状态中，对于任意一个类，都能知道这个类的所有属性和方法；对于任意一个对象，都能调用它的任意方法和属性；这种动态获取信息以及动态调用对象方法的功能称为Java语言的反射机制。

 用过反射吗？ 

Java反射的三种方法：

- 调用对象的getClass()方法。
- Class.forName("xxx.xxx.xxx")。
- 类名.class。

常用方法: 

- newInstance()：创建对象实例。
- getMethod()：可以获取所有public的方法（包含继承和实现的方法）。
- getDeclaredMethod()：获取指定对象的方法（不包含继承和实现方法）。
- setAccessible()：传入true/false，当设为true时可访问私有方法。
- Class.getField()：获取类中字段属性。
- Invoke()：可以用于执行指定的方法。

ClassLoader #

ClassLoader在Java中有着非常重要的作用，它主要工作在Class装载的加载阶段，其主要作用是从系统外部获得Class的二进制数据流。它是Java的核心组件，所有的Class都是由ClassLoader进行加载的。ClassLoader负责将Class文件里的二进制数据流装载进系统，然后交由Java虚拟机进行连接，初始化等操作。

 ClassLoader的种类 

- BootStrapClassLoader：它由C++编写，加载核心库java.*。
- ExtClassLoader：Java编写，加载扩展库Javax.*。
- AppClassLoader：Java编写，加载程序所在目录。
- 自定义ClassLoader：Java编写，定制化加载。

 自定义ClassLoader的实现 

自定义ClassLoader的实现有两个关键函数：

- findClass()

`java
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }
`

- defineClass()

`java
    protected final Class<?> defineClass(String name, byte[] b, int off, int len)
        throws ClassFormatError
    {
        return defineClass(name, b, off, len, null);
    }

`

 类加载器的双亲委派机制 

!双亲委派机制

在加载一个类时，会通过递归的方法，自底向上，首先看自定义类加载器中是否已经加载过相关类，若没有加载过，则调用父类加载器App ClassLoader的loadClass()方法看是否加载过，若还是没有就继续调用父类加载器Extension ClassLoader看是否加载过，直到检查到BootStrap ClassLoader。若都没加载过，就考虑自己是否具备加载的条件，如果不能加载，就自顶向下交给子类加载器进行加载。若还是无法加载，则抛出ClassNotFoundExcepiton异常。

 源码分析 

`java
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        // 类加载是线程安全的
        synchronized (getClassLoadingLock(name)) {
            // 首先，检查类是否已经被加载
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        // 递归调用检查父类加载器
                        c = parent.loadClass(name, false);
                    } else {
                        // 查找Bootstrap ClassLoader中是否加载了有关类
                        // 其中调用了findBootstrapClass 为native方法
                        // 因为Bootstrap类加载器是c++中实现的
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    //如果依然没找到，那么就调用自定义类加载器的findClass进行查找
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }
`

 为什么要使用双亲委派机制去加载类 

答：使用双亲委派机制能够避免多份同样的字节码重复加载。双亲委派机制能够保证同一份字节码文件只会被加载一次，并且可以保证一些核心的类不会被篡改替换，保证安全性。

 类的加载方式 

- 隐式加载：new，new后的对象实例无需再调用newInstance()方法来获取对象实例，new支持带参数的构造器生成对象实例。
- 显式加载：loadClass，forName。显式加载得到class对象后都需要调用newInstance()方法来获取对象实例。

 类的装载过程 

1. 加载

   - 通过ClassLoader加载class文件字节码，生成Class对象。

2. 链接

   - 校验：检查加载的class的正确性和安全性。
   - 准备：为类变量分配存储空间并设置类变量的初始值。
   - 解析：JVM将常量池内的符号引用转换为直接引用。

3. 初始化

   - 执行类变量赋值和静态代码块。

 loadClass和forName的区别 

- Class.forName()得到的class是已经初始化完成的。
- ClassLoader.loadClass()得到的class是还没有链接的。

Class.forName()代码实现：

`java
    public static Class<?> forName(String className)
                throws ClassNotFoundException {
        Class<?> caller = Reflection.getCallerClass();
        // 第二个参数被设为true，这个类将被初始化
        return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
    }
`

我们在实际场景中两种方法都会使用到。

例如在使用jdbc的mysql驱动时，我们需要使用Class.forName()方法来指定Driver。

`java
Class.forName("com.mysql.jdbc.Driver");
`

而在Spring IoC中，要读取一些Bean的配置文件时，如果以classpath方式来加载，则需要使用ClassLoader.loadClass()方式进行加载。这与Spring IoC容器的懒加载方式有关。Spring IoC为了加快初始化速度，大量使用懒加载方式来加速。而ClassLoader.loadClass()方法则可以对类进行延迟初始化，从而提升Spring的启动速度。

本文我整理了一些JVM类加载器相关的面试高频知识点，方便同学们复习。

JVM基础之类加载器详解

本文主要讲解Java程序中进程与线程的原理，将重要知识进行整理，并通过直观的Demo和图示进行讲解。

并发编程之Java进程与线程详解（进阶篇）

前言 #

本文主要讲解Java程序中进程与线程的相关的基础面试知识点，将重要知识进行整理，并通过直观的Demo和图示进行讲解。关于Java进程和线程更深层次的原理，我将在下一篇中进行讲解。

进程与线程 #

进程：进程独占内存空间，保存各自运行状态，相互间不干扰可以互相切换，为并发处理任务提供了可能。

线程：共享进程的内存资源，相互间切换更快速，支持更细粒度的任务控制，使进程内的子任务得以并发执行。

  进程和线程的区别 

1. 进程是资源分配的最小单位，线程是CPU调度的最小单位。
   - 所有进程相关的资源都被记录在PCB（进程控制块）中。
   - 进程是抢占处理机的调度单位；线程属于某个进程，共享其资源。
   - 线程只由堆栈寄存器、程序计数器和TCB（线程控制块）组成。
2. 线程不能看作独立应用，而进程可以看作独立应用。
3. 进程有独立的地址空间，相互不影响，线程只是进程的不同执行路径。
4. 线程没有独立地址空间，多进程的程序比多线程程序健壮。
5. 进程的切换比线程切换开销大。

 Java中进程和线程的关系 

- Java对操作系统提供的功能进行封装，包括进程和线程。
- 每运行一个程序产生一个进程，进程包含至少一个线程。
- 每个进程对应一个JVM实例，多个线程共享JVM里的堆。
- Java采用单线程编程模型，程序会自动创建主线程。
- 主线程可以创建子线程，原则上要后于子线程完成执行。

  线程的状态 

线程有六种状态：

1. 新建（New）：创建后尚未启动的线程的状态。
2. 运行（Runnable）：Runnable包含Running和Ready两个子状态。处于此状态的线程，有可能正在被执行，也有可能等待CPU为其分配执行时间。处于Running状态的线程位于可运行线程中，等待被线程调度选中，获取CPU的使用权，处于Ready状态的线程位于线程池中。处于Ready状态的线程在获得CPU时间后会转换为Running状态。
3. 无限等待（Waiting）：不会被分配CPU时间，需要被显式唤醒。以下两种情况会让线程位于无限等待状态：
   - 没有设置Timeout参数的Object.wait()方法。
   - 没有设置Timeout参数的Thread.join()方法。
   - 调用了LockSupport.part()方法。
4. 限期等待（Timed Waiting）：在一定时间后会由系统自动唤醒。
   - Thread.sleep()方法
   - 设置了Timeout参数的Object.wait()方法。
   - 设置了Timeout参数的Thread.join()方法。
   - LockSupport.parkNanos()方法。
   - LockSupport.parkUntil()方法。
5. 阻塞（Blocked）：等待获取排它锁。例如使用synchronized关键字修饰的线程在被其他线程访问时就会阻塞。
6. 结束（Terminated）：已终止线程的状态，线程已经结束执行。

 Thread中的start和run方法的区别 

- 调用start()方法会创建一个新的子线程并启动。
- run()方法只是Thread的一个普通方法的调用，并不会创建新的线程。

从JVM源码层面上分析，调用Thread中的start()方法时，会调用JVM中的JVM_StartThread方法创建一个新的子线程，该方法又会调用thread_entry方法，thread_entry会执行call_virtual调用虚拟机，最终调用run()方法中的内容。

!调用过程

 Thread和Runnable是什么关系 

- Thread是实现了Runnable接口的类，使得run方法支持多线程
- 因类的单一继承原则，推荐多使用Runnable接口。这样能够赋予子类较高的拓展性，便于后续将普通类升级成多线程。

 如何给run()方法传参 

- 构造函数传参
- 成员变量传参
- 回调函数传参

 如何实现处理线程的返回值 

> 在JDK1.5之前，线程是没有返回值的。开发者需要需要返回值时很不方便，需要使用其他方法或干脆不使用多线程。

- 主线程等待法：在主线程中使用while循环直到返回值不为空。这样做的缺点也很明显，我们需要手动去编写循环的逻辑，并且我们无法知道线程执行完成的具体时间，设置的sleep时长不精确。并且，当成员变量多的时候，我们的程序会显得异常臃肿无法维护。

- 使用Thread类的join()方法阻塞当前线程以等待子线程处理完毕。这样做的缺点是粒度不够细，无法精确控制成员之间的依赖关系。

- 通过Callable接口实现

  1. FutureTask

     Demo：

     MyCallable.java

     `java
     package com.yeliheng.threads;
     
     import java.util.concurrent.Callable;
     
     public class MyCallable implements Callable<String> {
         /
          * Computes a result, or throws an exception if unable to do so.
          *
          * @return computed result
          * @throws Exception if unable to compute a result
          */
         @Override
         public String call() throws Exception {
             String value = "test";
             Thread.sleep(5000);
             return value;
         }
     }
     `

     FutureTaskTest.java

     `java
     package com.yeliheng.threads;
     
     import java.util.concurrent.ExecutionException;
     import java.util.concurrent.FutureTask;
     
     public class FutureTaskTest {
         public static void main(String[] args) throws ExecutionException, InterruptedException {
             FutureTask<String> futureTask = new FutureTask<>(new MyCallable());
             new Thread(futureTask).start();
             if(!futureTask.isDone()) {
                 System.out.println("线程正在执行...");
             }
             System.out.println("返回值：" + futureTask.get());
         }
     }
     `

  2. 线程池

     Demo: 

     MyCallable.java与第一点内容完全相同。

     ThreadPoolTest.java

     `java
     package com.yeliheng.threads;
     
     import java.util.concurrent.ExecutionException;
     import java.util.concurrent.ExecutorService;
     import java.util.concurrent.Executors;
     import java.util.concurrent.Future;
     
     public class ThreadPoolTest {
         public static void main(String[] args) {
             ExecutorService newCachedThreadPool = Executors.newCachedThreadPool();
             Future<String> future = newCachedThreadPool.submit(new MyCallable());
             if(!future.isDone()) {
                 System.out.println("线程正在执行...");
             }
             try {
                 System.out.println("返回值: " + future.get());
             } catch (InterruptedException | ExecutionException e) {
                 e.printStackTrace();
             } finally {
                 newCachedThreadPool.shutdown();
             }
         }
     }
     
     `

 sleep和wait的区别 

基本区别：

- sleep是Thread类的方法，wait是Object类的方法。
- sleep方法可以在任何地方使用。
- wait方法只能在synchronized方法或synchronized块中使用。

最主要的本质区别：

- Thread.sleep()只会让出CPU，不会导致锁行为的改变。

- Object.wait()不仅会让出CPU，还会释放已经占有的同步资源锁。

Demo: 

`java
package com.yeliheng.threads;

public class SleepWaitTest {
    public static void main(String[] args) {
        final Object lock = new Object();
        // 线程A
        new Thread(() -> {
            System.out.println("线程A正在等待获得锁...");
            synchronized (lock) {
                try {
                    System.out.println("线程A休眠20毫秒");
                    Thread.sleep(20);
                    System.out.println("线程A执行wait方法");
                    // 此时，lock会让出CPU并释放资源锁
                    // B线程可以获取到锁
                    lock.wait(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
        // 线程B
        new Thread(() -> {
            System.out.println("线程B正在等待获得锁...");
            synchronized (lock) {
                try {
                    System.out.println("线程B获得锁");
                    Thread.sleep(10);
                    System.out.println("线程B执行完毕");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }

}
`

运行此段代码将输出：

`
线程A正在等待获得锁...
线程A休眠20毫秒
线程B正在等待获得锁...
线程A执行wait方法
线程B获得锁
线程B执行完毕

Process finished with exit code 0
`

可以看出，在线程A休眠后，线程B尝试获得锁，但此时锁并未被释放。直到线程A执行wait()方法，锁才被释放，线程b获得锁并执行相关逻辑。

 notify和notifyAll的区别 

- notifyAll会让所有处于等待池中的线程全部进入锁池去竞争获取锁的机会。
- notify只会随机选取一个处于等待池中的线程进入锁池去竞争获取锁的机会。

> 锁池：假设线程A已经拥有了某个对象（不是类）的锁，而其它线程B、C想要调用这个对象的某个synchronized方法（或者块），由于B、C线程在进入对象的synchronized方法（或者块）之前必须先获得该对象锁，而恰巧该对象的锁目前正在被A线程占用，此时B、C线程就会被阻塞，进入到一个地方去等待锁的释放，这个地方便是该对象的锁池。

> 等待池：假设线程A调用了某个对象的wait方法，线程A就会释放该对象的锁，同时线程A就进入到了该对象的等待池中，进入到等待池中的线程不会去竞争该对象的锁。

 yield是什么 

当调用Thread.yield()函数时，会给线程调度器一个当前线程愿意让出CPU使用的暗示，但是线程调度器可能会忽略这个暗示。

 如何中断线程 

- 已经弃用的方法：通过stop()方法停止线程。

- 调用interrupt()，通知线程应该中断了

  1. 如果线程处于被阻塞状态，那么线程将立即退出被阻塞状态，并抛出一个InterruptedException异常。
  2. 如果线程处于正常活动状态，那么会将该线程的中断标志设置为true。被设置中断标志的线程将继续正常运行，不受影响。

  调用interrupt不会立即中断线程，需要被调用的线程配合中断。在正常运行任务时，经常检查本线程的中断标志位，如果被设置了中断标志就自行停止线程。

总结 #

针对以上讲解的内容，我画了一张图进行总结。图中包含了进程状态的转换以及上文讲述到的方法内容。

!进程状态转换图

从图中可以清晰地看出进程状态的相互转换。

下一篇，我们将对Java进程和线程的进阶原理进行讲解。

本文主要讲解Java程序中进程与线程的相关的基础面试知识点，将重要知识进行整理，并通过直观的Demo和图示进行讲解。关于Java进程和线程更深层次的原理，我将在下一篇中进行讲解。

并发编程之Java进程与线程详解（基础篇）

上一篇我们详细了解了Java容器中的Collection体系，今天我们来对Java容器的另一个重要接口Map进行详细分析。Map 接口存在于java.util包中，它用于表示键和值之间的映射，Map的键是唯一的。Map十分适用于需要键值对映射的场景。

Java容器(二)——Map体系详解及源码分析

概述 #

Java的集合框架十分强大，它将常用的数据结构和算法进行封装，使得Java开发者无需精通底层数据结构和算法就可以轻松使用集合框架的API。例如最常见的数组、链表以及队列，栈再到二叉树，红黑树，JDK都将其进行不同程度的封装，极大提升了开发人员的开发效率。不过虽然我们在项目中无需直接接触此类底层逻辑，但我们还是需要熟练掌握其内容。因为在极端的业务场景下，我们可能需要对其底层数据结构进行调试甚至优化，所以熟练掌握底层结构也是必备技能。

以下是一张Collection接口图。

!Collection接口图
从图中我们可以看到，Collection接口拥有三个主要的子接口，分别是：Set、List、Queue。

详解-List #

我们首先来讲解List接口。

 List的特点 

- 存储的元素是有序（存储和取出的顺序）的。
- 同一元素可重复存储（可重复）。
- 可通过索引值操作元素。

---

List接口下包含有ArrayList、Vector、LinkedList三个类分别实现了List接口。

接下来我们来详细讨论其的区别。

我们根据底层数据结构的不同来将其分为两大类：

1. 底层是数组。数组查询快，增删慢。
2. 底层是链表。链表查询慢，增删快。

ArrayList和Vector属于底层是数组的分类。

 ArrayList和Vector的区别？ 

- ArrayList线程不安全，但效率高，适用于频繁的查找工作。
- Vector线程安全，但效率低。其也是Java早期提供线程安全的动态数组，不推荐在实际生产环境中使用。

 源码分析 

ArrayList.java

`java

    transient Object[] elementData; // non-private to simplify nested class access

    private int size;

    public ArrayList(int initialCapacity) {
        if (initialCapacity > 0) {
            this.elementData = new Object[initialCapacity];
        } else if (initialCapacity == 0) {
            this.elementData = EMPTY_ELEMENTDATA;
        } else {
            throw new IllegalArgumentException("Illegal Capacity: "+
                                               initialCapacity);
        }
    }

`

从源码可以看出，ArrayList中使用的是Object[]数组，并且查阅ArrayList源码，发现类中没有使用到synchronized和其他任何锁的关键字，故ArrayList是线程不安全。

`java

    public synchronized void copyInto(Object[] anArray) {
        System.arraycopy(elementData, 0, anArray, 0, elementCount);
    }

    public synchronized void trimToSize() {
        modCount++;
        int oldCapacity = elementData.length;
        if (elementCount < oldCapacity) {
            elementData = Arrays.copyOf(elementData, elementCount);
        }
    }

    public synchronized void ensureCapacity(int minCapacity) {
        if (minCapacity > 0) {
            modCount++;
            ensureCapacityHelper(minCapacity);
        }
    }

`

在Vector类中，同样使用了数组的结构，方法中都带有synchronized关键字，这就使得Vector天生线程安全。但大量使用同步锁造成在高并发场景下，将会有大量阻塞的线程等待，效率地下。
 LinkedList 

我们再来看看LinkedList。LinkedList底层是链表结构，线程不安全，效率高。

接下来我们来探讨ArrayList和LinkedList的区别。

 ArrayList和LinkedList的区别 

- ArrayList底层采用的是Object数组，而LinkedList底层采用的是双向链表的结构。

> 注：JDK1.6(包含)和之前采用的是双向循环链表，JDK1.7开始取消了循环。

> 引用 - 双向链表：包含两个指针，一个 prev 指向前一个节点，一个 next 指向后一个节点。

> 引用 - 双向循环链表：最后一个节点的 next 指向 head，而 head 的 prev 指向最后一个节点，构成一个环。

- ArrayList 插入和删除的时间复杂度受元素位置的影响。原因如下：ArrayList会将元素追加到末尾，此时，时间复杂度为O(1)。这时我们通过索引在指定的位置i插入或删除元素，那么时间复杂度则为O(n-i) (n为数组的长度)。这是因为数组中第i个和第i个之后的(n-i)个元素都要跟着向后或向前移动一位。
- LinkedList 插入和删除的时间复杂度不受元素位置影响。因为其数据结构为双向链表，所以在add(E e)、addFirst(E e)、addLast(E e)、removeFirst() 、 removeLast()操作中，其时间复杂度为O(1)，而通过索引下标i进行插入或删除操作时间复杂度为O(n)。这是因为链表指针需要移动到指定位置后插入。
- ArrayList支持RandomAccess（即高效的随机访问），而LinkedList则不支持。

 源码分析 

`java
    /
     * Pointer to first node.
     * Invariant: (first == null && last == null) ||
     *            (first.prev == null && first.item != null)
     */
    transient Node<E> first;

    /
     * Pointer to last node.
     * Invariant: (first == null && last == null) ||
     *            (last.next == null && last.item != null)
     */
    transient Node<E> last;
`

上图为LinkedList的部分源码。LinkedList类定义了first和last两个Node结点，分别指向头元素和尾元素，是典型的链表结构。

LinkedList类没有用到锁，故其也是线程不安全的。

`java
public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable
{...}
`

ArrayList实现了RandomAccess，这个接口与Cloneable一样，只是作为一个标识。说明ArrayList支持高效的随机访问，实现Cloneable说明该类支持克隆。同时，实现了Serializable接口说明该类可被序列化。

`java
public class LinkedList<E>
    extends AbstractSequentialList<E>
    implements List<E>, Deque<E>, Cloneable, java.io.Serializable
{...}
`

可以看到LinkedList并没有支持高效的随机访问。其实现了一个双端队列Deque，其余部分与ArrayList同理。

 ArrayList的扩容机制 

ArrayList是动态数组，与传统数组相比，它的容量能够动态增长。在源码中，扩容的核心方法是grow()，此处我们详细分析grow()方法，若要了解详细的扩容机制，可自行查阅源码或搜索相关资料。

 源码分析 

`java
    // minCapacity: 最小需要容量
    private void grow(int minCapacity) {
        // oldCapacity: 旧容量，newCapacity: 新容量
        int oldCapacity = elementData.length;
        int newCapacity = oldCapacity + (oldCapacity >> 1);
        if (newCapacity - minCapacity < 0)
            newCapacity = minCapacity;
        // 此处MAX_ARRAY_SIZE常量值为：Integer.MAX_VALUE - 8
        if (newCapacity - MAX_ARRAY_SIZE > 0)
            newCapacity = hugeCapacity(minCapacity);
        // minCapacity is usually close to size, so this is a win:
        elementData = Arrays.copyOf(elementData, newCapacity);
    }
`

解释：int newCapacity = oldCapacity + (oldCapacity >> 1);此语句的意思是将oldCapacity做右移一位的运算，其效果相当于oldCapacity / 2。此处使用为位运算而不直接使用除法运算目的在于：位运算速度比除法运算快得多，有助于提升效率，节省资源。

grow方法的逻辑：先将oldCapacity右移一位，然后判断新容量是否小于最小需要容量，若条件满足（即newCapacity < minCapacity），则将新容量设为传入的最小需要容量。

若新容量大于MAX_ARRAY_SIZE，则调用hugeCapacity()方法来比较minCapacity和MAX_ARRAY_SIZE。
hugeCapacity代码如下：

`java
    private static int hugeCapacity(int minCapacity) {
        if (minCapacity < 0) // overflow
            throw new OutOfMemoryError();
        return (minCapacity > MAX_ARRAY_SIZE) ?
            Integer.MAX_VALUE :
            MAX_ARRAY_SIZE;
    }
`
即：如果minCapacity大于最大容量，则新容量则为Integer.MAX_VALUE，否则，新容量大小则为 MAX_ARRAY_SIZE 即为 Integer.MAX_VALUE - 8。

最后，使用Arrays.copyOf();方法生成一个新的扩容好的数组，并将其赋值给原始数组即elementData。这就实现了数组的扩容操作。

此外，ArrayList还提供了可供外部调用的扩容方法ensureCapacity。

`java
    public void ensureCapacity(int minCapacity) {
        int minExpand = (elementData != DEFAULTCAPACITY_EMPTY_ELEMENTDATA)
            // any size if not default element table
            ? 0
            // larger than default for default empty table. It's already
            // supposed to be at default size.
            : DEFAULT_CAPACITY;

        if (minCapacity > minExpand) {
            ensureExplicitCapacity(minCapacity);
        }
    }
`
通过源码可以看出，ensureCapacity方法使用的是public修饰符，可供开发者进行调用。在添加大量元素前，开发者可以通过ensureCapacity动态地为数组扩展容量，这样可以避免频繁地扩容带来的性能损失。此处不是此篇的重点，具体感兴趣可自行查看源码。

详解-Set #

Set也是Collection的重要子接口之一。从文章开头的框架图可以看出，Set下包含HashSet、LinkedHashSet、TreeSet等子接口。

 Set的特点 

- 无序性：即存储的元素是无序（存储和取出的顺序）的。
- 唯一性：所有的元素都是唯一的。

Set适合应用在需要去重的场景中。

将Set进行分类，我们同样能够将其分为两大类：

1. 底层是哈希表，即HashMap，在下文源码中可以看出。具体HashMap的实现，我将于下一篇进行介绍。
2. 底层是二叉树。

HashSet和LinkedHashSet属于第一种分类，即底层是哈希表（LinkedHashSet底层是哈希表+链表）。TreeSet则属于底层是二叉树的分类。

HashSet使用hashCode()和equals()来保证元素的唯一性。

 源码分析 

我们来看HashSet的两个源码片段。

`java
public HashSet(int initialCapacity) {
    map = new HashMap<>(initialCapacity);
}
`
`java
public boolean add(E e) {
    return map.put(e, PRESENT)==null;
}
`

从源码可以看出HashSet在初始化时创建了一个HashMap对象。在添加元素的时候，我们可以看到，元素其实是以键的形式存储在HashMap中，对应的值为一个PRESENT的常量。PRESENT的值实际上是一个final的Object对象。这就解释了HashSet如何保证元素的唯一性。

HashSet常用于保证元素唯一性的场景，而TreeSet常用于对排序有要求的场景。在不需要排序的场景下使用HashSet可以获得更好的性能。

谈起排序，我们来具体讨论一下Comparable和Comparator接口。

- Comparable接口在java.lang包，它有一个 compareTo(Object obj)方法用于排序。
- Comparator接口在java.util包，它有一个compare(Object obj1, Object obj2)方法用于排序。

 Comparable和Comparator接口的区别 

- Comparable接口是一个自然排序接口，它用于实现自然排序，compareTo也称为自然比较方法。当开发者调用Collections中的sort方法时，对象可按照自身实现的Comparable进行自然排序。这个对象必须实现Comparable接口。
- Comparator接口可以理解为定制化排序接口，开发者可对没有实现Comparable接口的类进行定制化排序，而无需修改类的源码。

 TreeSet源码分析 

TreeSet类就同时提供了Comparable和Comparator两种排序的方式。具体我们追溯到源码。

`java
public TreeSet() {
    this(new TreeMap<E,Object>());
}

public TreeSet(Comparator<? super E> comparator) {
    this(new TreeMap<>(comparator));
}
`

通过源码可以看出，TreeSet底层是通过TreeMap实现的，所以我们需要进一步进入到TreeMap中查看具体排序的逻辑。TreeSet的构造函数提供了一个无参构造函数和一个有参构造函数。无参构造函数在TreeMap中将会使用Comparable的自然排序，而有参构造函数传入了一个Comparator对象。

现在我们进入到TreeMap中进行查看。

`java
final Entry<K,V> getEntry(Object key) {
    // Offload comparator-based version for sake of performance
    if (comparator != null)
        return getEntryUsingComparator(key);
    if (key == null)
        throw new NullPointerException();
    @SuppressWarnings("unchecked")
        Comparable<? super K> k = (Comparable<? super K>) key;
    Entry<K,V> p = root;
    while (p != null) {
        int cmp = k.compareTo(p.key);
        if (cmp < 0)
            p = p.left;
        else if (cmp > 0)
            p = p.right;
        else
            return p;
    }
    return null;
}
`

通过源码可以看出，在comparator不为空的时候，getEntry方法会调用getEntryUsingComparator，进而就调用了我们自定义的排序方法。默认则是通过Comparable接口进行自然排序。

 HashSet、LinkedHashSet、TreeSet比较 

- HashSet、LinkedHashSet、TreeSet都是Set接口的实现类，都能保证元素唯一，都不是线程安全的。
- HashSet底层数据结构为哈希表，基于HashMap进行实现。LinkedHashSet的底层数据结构是链表+哈希表。元素的插入和取出顺序是先进先出。TreeSet的底层数据结构是红黑树（自平衡二叉查找树）。
- HashSet适用于不需要保证元素插入和取出顺序和不关心排序的场景，LinkedHashSet适用于保证元素的插入和取出顺序满足先进先出的场景，TreeSet适用于需要自定义排序规则的场景。

补充-Queue #

Queue是单端队列，即元素只能从一段插入，另一端删除，一般遵循FIFO即先进先出原则。它扩展了Collection接口。

Deque是双端队列，即队列两队均可插入或删除元素。它扩展了Queue接口，并且提供push和pop等特殊方法，可用于模拟栈结构。

Deque接口下用得较多的就是LinkedList类，具体可查看前文内容。

总结 #

在本文的末尾，我总结了一个表格对比了上文讲述的对象的特点。

| 对象 | 底层数据结构 | 是否线程安全 |
| --- | --- | --- |
| ArrayList | 数组 | 否 | 
| Vector | 数组 | 是 |
| LinkedList | 链表 | 否 |
| HashSet | 哈希表 | 否 |
| LinkedHashSet | 哈希表+链表 | 否 |
| TreeSet | 红黑树 | 否 |

Java容器中的Collection是一个面试常考/必考的知识点，并且在开发中也十分常用。熟练掌握Collection体系内容是极其必要的。

Java的集合框架十分强大，它将常用的数据结构和算法进行封装，使得Java开发者无需精通底层数据结构和算法就可以轻松使用集合框架的API。例如最常见的数组、链表以及队列，栈再到二叉树，红黑树，JDK都将其进行不同程度的封装，极大提升了开发人员的开发效率。不过虽然我们在项目中无需直接接触此类底层逻辑，但我们还是需要熟练掌握其内容。

Java容器(一)——Collection体系详解及源码分析

# 👋 Hey，我是 Yeliheng

Java 后端工程师，专注构建高并发、高可用系统，关注架构的鲁棒性和可扩展性。

追求代码的表达力与演进能力，热衷以工程化手段提升系统韧性与开发效率。

## 💻 专攻领域

- Java / JUC / 并发控制 / 函数式编程
- Spring 全家桶及底层：Spring / Spring Boot / Spring Cloud
- 消息系统：RabbitMQ，熟悉队列设计与消息幂等
- 数据存储：MySQL / MongoDB / Redis，熟悉分片、事务与调优
- 分布式基础设施：Docker / Kubernetes / Jenkins / GitOps
- 数据监控：Prometheus / Grafana / ELK / Alertmanager

## 📫 联系方式

- GitHub: [🔗 Yeliheng](https://github.com/yeliheng)
- Email: yeliheng00@gmail.com
