【Java开发岗：基础篇】

点击：【第一章：Java开发岗：基础篇】

计算机基础问题、HashMap、Fail-safe机制/Fail-fast机制、Synchronized、ThreadLocal、AQS、线程池、JVM内存模型、内存屏障、class文件结构、类加载 机制、双亲委派、垃圾回收算法、垃圾回收器、空间分配担保策略、安全点、JIT技术、可达性分析、强软弱虚引用、gc的过程、三色标记、跨代引用、 逃逸分析、 内存泄漏与溢出、JVM线上调优、CPU飙高系统反应慢怎么排查。

点击：【第二章：Java开发岗：MySQL篇】

隔离级别、ACID底层实现原理、 一致性非锁定读（MVCC的原理）、BufferPool缓存机制、filesort过程、 离散读、ICP优化、全文检索、 行锁、表锁、间隙锁、死锁、主键自增长实现原理、索引数据结构、SQL优化、索引失效的几种情况、聚集索引、辅助索引、覆盖索引、联合索引、redo log、bin log、undolog、分布式事务、SQL的执行流程、重做日志刷盘策略、有MySQL调优、分库分表、主从复制、读写分离、高可用。

点击：【第三章：Java开发岗：Redis篇】

多路复用模式、单线程模型、简单字符串、链表、字典、跳跃表、压缩列表、encoding属性编码、持久化、布隆过滤器、分布式寻址算法、过期策略、内存淘汰策略 、Redis与数据库的数据一致性、Redis分布式锁、热点数据缓存、哨兵模式、集群模式、多级缓存架构、并发竞争、主从架构、集群架构及高可用、缓存雪崩、 缓存穿透、缓存失效。

点击：【第四章：Java开发岗：MQ篇】

RabbitMQ、RockerMQ、Kafka 三种消息中间件出现的消息可靠投递、消息丢失、消息顺序性、消息延迟、过期失效、消息队列满了、消息高可用等问题的解决方案。RabbitMQ的工作模式，RocketMQ的消息类型，Kafka消费模式、主题/分区/日志、核心总控制器以及它的选举机制、Partition副本选举Leader机制、消费者消费消息的offset记录机制、消费者Rebalance机制、Rebalance分区分配策略、Rebalance过程、 producer发布消息机制、HW与LEO、日志分段存储、十亿消息数据线上环境规划、JVM参数设置。

点击：【第五章：Java开发岗：Spring篇】

SpringBean生命周期、Spring循环依赖、Spring容器启动执行流程、Spring事务底层实现原理、Spring IOC容器加载过程、Spring AOP底层实现原理、Spring的自动装配、Spring Boot自动装配、Spring Boot启动过程、SpringMVC执行流程、Mybatis的缓存机制。

点击：【第六章：Java开发岗：SpringCould篇】

微服务构建、客户端负载均衡、服务治理、服务容错保护、声明式服务调用、API网关服务、分布式配置中心、消息总线、消息驱动、分布式服务追踪、分布式事务、流量控制。

点击：【第七章：Java开发岗：项目篇】

简历上面的项目经历怎么写(项目介绍、负责模块、使用技术)，面试项目实战（秒杀下单设计、权限设计、红包雨设计）

---

系列文章：每篇文章字数都是大几万，保证质量，文章以备战面试为背景，薪资参考坐标：上海；每个地方，每个时间段薪资待遇都不一样，文章仅做面试参考，具体能否谈到理想的薪资取决于面试表现、平时的积累、市场行情、机遇。
提示：系列文章还未全部完成，后续的文章，会慢慢补充进去的。

这里总结一下35k的Java开发岗需要掌握的面试题，帮助大家快速复习，突破面试瓶颈。本章主讲Java基础知识点，知识点有： 计算机基础问题、HashMap、Fail-safe机制/Fail-fast机制、Synchronized、ThreadLocal、AQS、线程池、JVM内存模型、内存屏障、class文件结构、类加载 机制、双亲委派、垃圾回收算法、垃圾回收器、空间分配担保策略、安全点、JIT技术、可达性分析、强软弱虚引用、gc的过程、三色标记、跨代引用、 逃逸分析、 内存泄漏与溢出、JVM线上调优、CPU飙高系统反应慢怎么排查。大致估算可以讲八小时左右，作为备战面试的基础知识点还是很不错的。35k薪资参考的坐标：上海，参考时间：2022年8月

计算机基础问题

深拷贝和浅拷贝

深拷贝和浅拷贝是用来描述对象或者对象数组这种引用数据类型的复制场景的。

浅拷贝就是只复制某个对象的指针，而不复制对象本身。

这种复制方式意味着两个引用指针指向被复制对象的同一块内存地址。

深拷贝会完全创建一个一模一样的新对象，新对象和老对象不共享内存，也就意味着对新对象的修改不会影响老对象的值。

在Java里面，无论是深拷贝还是浅拷贝，都需要通过实现Cloneable接口，并实现clone()方法。

然后我们可以在clone()方法里面实现浅拷贝或者深拷贝的逻辑。

实现深拷贝的方法有很多，比如

• 通过序列化的方式实现，也就是把一个对象先序列化一遍，然后再反序列化回来，就会得到一个完整的新对象。

• 在clone()方法里面重写克隆逻辑，也就是对克隆对象内部的引用变量再进行一次克隆。

伪共享的概念以及如何避免

首先，计算机工程师为了提高CPU的利用率，平衡CPU和内存之间的速度差异，在CPU里面设计了三级缓存。

CPU在向内存发起IO操作的时候，一次性会读取64个字节的数据作为一个缓存行，缓存到CPU的高速缓存里面。

在Java中一个long类型是8个字节，意味着一个缓存行可以存储8个long类型的变量。

这个设计是基于空间局部性原理来实现的，也就是说，如果一个存储器的位置被引用，那么将来它附近的位置也会被引用。

所以缓存行的设计对于CPU来说，可以有效的减少和内存的交互次数，从而避免了CPU的IO等待，以提升CPU的利用率。

正是因为这种缓存行的设计，导致如果多个线程修改同一个缓存行里面的多个独立变量的时候，基于缓存一致性协议，就会无意中影响了彼此的性能，这就是伪共享的问题。

像这样一种情况，CPU0上运行的线程想要更新变量X、CPU1上的线程想要更新变量Y，而X/Y/Z都在同一个缓存行里面。

每个线程都需要去竞争缓存行的所有权对变量做更新，基于缓存一致性协议。

一旦运行在某个CPU上的线程获得了所有权并执行了修改，就会导致其他CPU中的缓存行失效。

这就是伪共享问题的原理。

因为伪共享会问题导致缓存锁的竞争，所以在并发场景中的程序执行效率一定会收到较大的影响。

这个问题的解决办法有两个：

• 使用对齐填充，因为一个缓存行大小是64个字节，如果读取的目标数据小于64个字节，可以增加一些无意义的成员变量来填充。

• 在Java8里面，提供了@Contented注解，它也是通过缓存行填充来解决伪共享问题的，被@Contented注解声明的类或者字段，会被加载到独立的缓存行上。

在Netty里面，有大量用到对齐填充的方式来避免伪共享问题。

网络四元组

四元组，简单理解就是在TCP协议中，去确定一个客户端连接的组成要素，它包括源IP地址、目标IP地址、源端口号、目标端口号。

正常情况下，我们对于网络通信的认识可能是这样

服务端通过ServerSocket建立一个对指定端口号的监听，比如8080。 客户端通过目标ip和端口就可以和服务端建立一个连接，然后进行数据传输。

但是我们知道的是，一个Server端可以接收多个客户端的连接，比如像这种情况

那，当多个客户端连接到服务端的时候，服务端需要去识别每一个连接。

并且TCP是全双工协议，也就是说数据允许在连接的两个方向上同时传输，因此这里的客户端，如果是反向通信，它又变成了服务端。

所以基于这两个原因，就引入了四元组的设计，也就是说，当一个客户端和服务端建立一个TCP连接的时候，通过源IP地址、目标IP地址、源端口号、目标端口号来确定一个唯一的TCP连接。因为服务器的IP和端口是不变的，只要客户端的IP和端口彼此不同就OK了。

比如像这种情况

同一个客户端主机上有三个连接连到Server端，那么这个时候源IP相同，源端口号不同。此时建立的四元组就是（10.23.15.3，59461 ， 192.168.8.135，8080）

其中，源端口号是每次建立连接的时候系统自动分配的。

TCP协议为什么要设计三次握手？

关于这个问题，我会从下面3个方面来回答。

1.TCP协议，是一种可靠的，基于字节流的，面向连接的传输层协议。

• 可靠性体现在TCP协议通信双方的数据传输是稳定的，即便是在网络不好的情况下，TCP都能够保证数据传输到目标端，而这个可靠性是基于数据包确认机制来实现的。

• TCP通信双方的数据传输是通过字节流来实现传输的

• 面向连接，是说数据传输之前，必须要建立一个连接，然后基于这个连接进行数据传输

2.因为TCP是面向连接的协议，所以在进行数据通信之前，需要建立一个可靠的连接，TCP采用了三次握手的方式来实现连接的建立。所谓的三次握手，就是通信双方一共需要发送三次请求，才能确保这个连接的建立。

• 客户端向服务端发送连接请求并携带同步序列号SYN。
• 服务端收到请求后，发送SYN和ACK， 这里的SYN表示服务端的同步序列号，ACK表示对前面收到请求的一个确认，表示告诉客户端，我收到了你的请求。
• 客户端收到服务端的请求后，再次发送ACK，这个ACK是针对服务端连接的一个确认，表示告诉服务端，我收到了你的请求。
  

3.之所以TCP要设计三次握手，我认为有三个方面的原因：

• TCP是可靠性通信协议，所以TCP协议的通信双方都必须要维护一个序列号，去标记已经发送出去的数据包，哪些是已经被对方签收的。而三次握手就是通信双方相互告知序列号的起始值，为了确保这个序列号被收到，所以双方都需要有一个确认的操作。

• TCP协议需要在一个不可靠的网络环境下实现可靠的数据传输，意味着通信双方必须要通过某种手段来实现一个可靠的数据传输通道，而三次通信是建立这样一个通道的最小值。当然还可以四次、五次，只是没必要浪费这个资源。

• 防止历史的重复连接初始化造成的混乱问题，比如说在网络比较差的情况下，客户端连续多次发送建立连接的请求，假设只有两次握手，那么服务端只能选择接受或者拒绝这个连接请求，但是服务端不知道这次请求是不是之前因为网络堵塞而过期的请求，也就是说服务端不知道当前客户端的连接是有效还是无效。

HashMap

hashmap几乎是Java面试必问题，相关的知识点其实有很多，更为详细的hashmap知识点，我也有写，全部讲一遍，差不多要一个小时以上，有时间的同学可以去看看，这里提供地址：https://blog.csdn.net/java_wxid/article/details/124788118，面试官想问的可能就那么几个，另外还需要控制hashmap讲解的时长，挑几个比较重要的，进行讲解即可，下面由浅到深讲解，专门针对面试题，归总的知识点列举出来。

HashMap底层实现

向HashMap中添加一个元素时，当前元素的key会调用hashCode方法来决定它在数组中存放的位置。如果这个位置没有其他元素，会把这个键值对直接放到一个node类型的数组中，这个数组就是hashmap底层基础的数据结构。如果这个位置有其他元素，会继续拿着这个key调用equals方法和这个位置已存在的元素key进行对比，对比二个元素的key。key一样，返回true，原来的value值会被替换成新的value。key不一样，返回flase，这个位置就用链表的形式把多个元素串起来存放。

jdk1.7版本的HashMap数据结构就是数组加链表的形式存储元素的，但是会有弊端，当链表中的数据较多时，查询的效率会下降。所以JDK1.8版本做了一个升级，当链表长度大于8，并且数组长度大于64时，会转换为红黑树。因为红黑树需要进行左旋，右旋，变色操作来保持平衡，如果当数组长度小于64，使用数组加链表比使用红黑树查询速度要更快、效率更高。

在HashMap源码有这样一段描述，大致意思是说在理想状态下受随机分布的hashCode影响，链表中的节点遵循泊松分布，节点数是8的概率接近千分之一，这个时候链表的性能很差，所以在这种比较罕见和极端的情况下才会把链表转变为红黑树，大部分情况下HashMap还是使用链表，如果理想情况下，均匀分布，节点数不到8就已经自动扩容了。

1.7版本和1.8版本的差异

jdk1.7的hashmap有二个无法忽略的问题。

• 第一个是扩容的时候需要rehash操作，将所有的数据重新计算HashCode，然后赋给新的HashMap，rehash的过程是非常耗费时间和空间的。

• 第二个是当并发执行扩容操作时会造成环形链和数据丢失的情况，开多个线程不断进行put操作，当旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，就是因为头插法，所以最后的结果打乱了插入的顺序，就有可能发生环形链和数据丢失的问题，引起死循环，导致CPU利用率接近100%。

在JDK1.8中，对HashMap这二点进行了优化。

• 第一点是经过rehash之后元素的位置，要么是在原位置，要么是原位置+原数组长度。不需要像JDK1.7的实现那样重新计算hash，只需要看看原来的hash值新增的那个bit是1还是0就好了。在数组的长度扩大到原来的2倍， 4倍，8倍时，在resize(也就是length - 1)这部分，相当于在高位新增一个或多个1bit。

  举个例子，hashmap默认的初始长度是16，负载因子是0.75，当元素被使用75%以上时，触发扩容操作，并且每次扩容一倍。扩容时：将旧数组中的元素转换后，填充到新数组中。通过底层获取索引indexfor方法里面有个（length -1）公式，取它的二进制，它的二进制位后八位是0000 1111，扩容二倍到32，通过公式（length -1）取31的二进制，它的后八位0001 1111，可以发现它的高位进的是1，然后和原来的hash码进行与操作，这样元素在数组中映射的位置要么不变，要不就是在原位置再移动2次幂的位置。

  高位上新增的是1的话索引变成原位置+原数组长度，是0的话索引没变。这样既省去了重新计算hash值的时间，而且由于高位上新增的1bit是0还是1，可以认为是随机的，复杂度更高，从而让分布性更高些。

• 第二点，发生hash碰撞，不再采用头插法方式，而是直接插入链表尾部，因此不会出现环形链表的情况，但是在多线程环境下，会发生数据覆盖的情况。

  举个例子，如果没有hash碰撞的时候，它会直接插入元素。如果线程A和线程B同时进行put操作，刚好这两条不同的数据hash值一样，并且该位置数据为null，线程A进入后还未进行数据插入时挂起，而线程B正常执行，从而正常插入数据，然后线程A获取CPU时间片，此时线程A不用再进行hash判断了，线程A会把线程B插入的数据给覆盖，导致数据发生覆盖的情况，发生线程不安全。

并发修改异常解决方案

HashMap在高并发场景下会出现并发修改异常，导致原因：并发争取修改导致，一个线程正在写，一个线程过来争抢，导致线程写的过程被其他线程打断，导致数据不一致。

• 第一种解决方案：使用HashTable：HashTable是线程安全的，只不过实现代价却太大了，简单粗暴，get/put所有相关操作都是synchronized的，这相当于给整个哈希表加了一把大锁。多线程访问时候，只要有一个线程访问或操作该对象，那其他线程只能阻塞，相当于将所有的操作串行化，在竞争激烈的并发场景中性能就会非常差。

• 第二种解决方案：使用工具类Collections.synchronizedMap(new HashMap<>());和Hashtable一样，实现上在操作HashMap时自动添加了synchronized来实现线程同步，都对整个map进行同步，在性能以及安全性方面不如ConcurrentHashMap。

• 第三种解决方案：使用写时复制（CopyOnWrite）：往一个容器里面加元素的时候，不直接往当前容器添加，而是先将当前容器的元素复制出来放到一个新的容器中，然后新的元素添加元素，添加完之后，再将原来容器的引用指向新的容器，这样就可以对它进行并发的读，不需要加锁，因为当前容器不添加任何元素。利用了读写分离的思想，读和写是不同的容器。缺点也很明显，会有内存占用问题，在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存。会有数据一致性问题，CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。

• 第四种解决方案：使用ConcurrentHashMap：ConcurrentHashMap大量的利用了volatile，CAS等技术来减少锁竞争对于性能的影响。在JDK1.7版本中ConcurrentHashMap避免了对全局加锁，改成了局部加锁（分段锁），分段锁技术，将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问，能够实现真正的并发访问。不过这种结构的带来的副作用是Hash的过程要比普通的HashMap要长。所以在JDK1.8版本中CurrentHashMap内部中的value使用volatile修饰，保证并发的可见性以及禁止指令重排，只不过volatile不保证原子性，使用为了确保原子性，采用CAS（比较交换）这种乐观锁来解决。

加载因子

加载因子是用来判断当前HashMap<K,V>中存放的数据量，默认的加载因子是0.75。

加载因子比较大，扩容发生的频率比较低，浪费的空间比较小，发生hash冲突的几率比较大。

• 比如，加载因子是1的时候，hashmap长度为128，实际存储元素的数量在64至128之间时间段比较多，这个时间段发生hash冲突比较多，造成数组中其中一条链表比较长，会影响性能。

加载因子比较小，扩容发生的频率比较高，浪费的空间比较多，发生hash冲突的几率比较小。

• 比如，加载因子是0.5的时候，hashmap长度为128，当数量达到65的时候会触发扩容，扩容后为原理的256，256里面只存储了65个，浪费了。综合了一下，取了一个平均数0.75作为加载因子。

长度恒定为2的n次方

HashMap的数组长度恒定为2的n次方，也就是说只会为16，32，64这种数。即便你给的初始值是13，最后数组长度也会变成16，它会取你传进来的数，最近一个2的n次方的数。这么设计的目的主要是为了解决底层运算后的值可以落到数组的每个下标上面。
hashMap获取索引的方法：

//indexFor中的h是hashCode通过变换之后的值，是一个32位的二进制数
public static int indexFor(int h, int length) {
    return h & (length-1);
}

HashMap中运算数组的位置，使用的是length-1，每次扩容会把原数组的长度*2，在二进制上的表现就是高位进1，并且后四位始终都是1111。

初始长度为16的数组，对应的length-1就是15，原数组15二进制后八位为0000 1111。
扩容后的长度为32的数组，对应的length-1就是31，二进制就变成了0001 1111。
再次扩容长度为64的数组，对应的length-1就是63，二进制是0011 1111。

假设hashMap容量为16
hash值&运算：

11001110 11001111 00010011 11110001（hash值）
&
00000000 00000000 00000000 00001111（16-1的2进制）
=
00000000 00000000 00000000 00000001

hash的2进制的后4位和1111比较，hash值的后4位范围是0000-1111之间，与上1111，最后的值是在0000-1111，也就是0-15之间。这样就保证运算后的值可以落到数组的每一个下标。

如果数组长度不是2的幂次，后四位就不可能是1111，0000~1111的一个数和有可能不是1111的数进行&运算，数组的某几位下标就有可能永远不会有值，这就没法保证运算后的值可以落到数组的每个下标上面。

散列均匀分布

hashMap获取索引的indexFor方法里面的h是hashCode通过变换之后的值，是一个32位的二进制数，如果直接用如此长的二进制数和目标length-1直接进行与运算，结果会导致高位会大量丢失。

假如我们以16位为划分，任何两个高16位不一样，低16位一样的数。这两个数的hashCode与length-1做与运算（hashCode & length-1），结果会是一样的，这样的两个数，却产生了相同的hash结果，发生hash冲突。

于是hashMap想到了一种处理方式：底层算法通过让32位hashcode中保持高16位不变，高16与低16异或结果，作为新的低16位，然后用hash得到的结果（int h）传入方法indexFor获取到hashMap的索引。

计算中只有低位16位参与&运算，计算效率高，同时也保证的hash的高16位参与了索引运算，这样得到的索引能呈较为理想的散列分布，在将条目放入hashMap中时，最大限度避免hash碰撞。

static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);//把hash值异或了hash值右移16位，即取高16位
}

绝大多数情况下length一般都小于2^16即小于65536，所以indexFor方法中return h & (length-1)的结果始终是h的低16位与（length-1）进行&运算。hashmap为了考虑性能的设计还是非常精妙的。

hashmap优化

对hashmap使用的优化，我个人看法有五点。

• 第一点，建议采用短String，Integer这样的类作为键。特别是String，他是不可变的，也是final的，而且已经重写了equals和hashCode方法，契合HashMap要求的计算hashCode的不可变性要求，核心思想就是保证键值的唯一性，不变性，其次是不可变性还有诸如线程安全的问题，这么定义键，可以最大限度的减少碰撞的出现。如果hashCode不冲突，那查找效率很高，但是如果hashCode一旦冲突，要调用equals一个字节一个自己的去比较，key越短效率越高。

• 第二点不使用for循环遍历map，而是使用迭代器遍历Map，使用迭代器遍历entrySet在各个数量级别效率都比较高。

• 第三点使用线程安全的ConcurrentHashMap来删除Map中的元素，或者在迭代器Iterator遍历时，使用迭代器iterator.remove()来删除元素。不可以for循环遍历删除，否则会产生并发修改异常CME。

• 第四点考虑加载因子地设定初始大小，设定时一定要考虑加载因子的存在，使用的时候最好估算存储的大小。可以使用Maps.newHashMapWithExpectedSize(预期大小)来创建一个HashMap，计算的过程guava会帮我们完成，Guava的做法是把默认容量的数字设置成预期大小 / 0.75F + 1.0F。

• 第五点减小加载因子​，如果Map是一个长期存在而不是每次动态生成的，而里面的key又是没法预估的，那可以适当加大初始大小，同时减少加载因子，降低冲突的机率。毕竟如果是长期存在的map，浪费点数组大小不算啥，降低冲突概率，减少比较的次数更重要。

Fail-safe机制/Fail-fast机制

Fail-safe和Fail-fast，是多线程并发操作集合时的一种失败处理机制。

Fail-fast ： 表示快速失败，在集合遍历过程中，一旦发现容器中的数据被修改了，会立刻抛出ConcurrentModificationException异常，从而导致遍历失败，像这种情况
定义一个Map集合，使用Iterator迭代器进行数据遍历，在遍历过程中，对集合数据做变更时，就会发生Fail-fast。

java.util包下的集合类都是快速失败机制的, 常见的的使用Fail-fast方式遍历的容器有HashMap和ArrayList等。

Fail-safe：表示失败安全，也就是在这种机制下，出现集合元素的修改，不会抛出ConcurrentModificationException。

原因是采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，

在拷贝的集合上进行遍历。由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到

比如这种情况

定义了一个CopyOnWriteArrayList，在对这个集合遍历过程中，对集合元素做修改后，不会抛出异常，但同时也不会打印出增加的元素。

java.util.concurrent包下的容器都是安全失败的,可以在多线程下并发使用,并发修改。

常见的的使用Fail-safe方式遍历的容器有ConcerrentHashMap和CopyOnWriteArrayList等。

Synchronized

Synchronized是Java高频面试题，相关的知识点其实有很多，更为详细的Synchronized知识点，我也有写，全部讲一遍，差不多要一个小时以上，有时间的同学可以去看看，这里提供地址：https://liaozhiwei.blog.csdn.net/article/details/124900072，面试官想问的主要是锁的升级过程，下面由浅到深讲解，专门针对面试题，归总的知识点列举出来。

定义

Synchronized是Java语言的关键字，它保证同一时刻被Synchronized修饰的代码最多只有1个线程执行。

应用场景

synchronized如果加在方法上/对象上，那么，它作用的对象是非静态的，它取得的锁是对象锁；
synchronized如果作用的对象是一个静态方法或一个类，它取到的锁是类锁，这个类所有的对象用的是同一把锁。
每个对象只有一个锁，谁拿到这个锁，谁就可以运行它所控制的那段代码。

对象加锁实现原理

在Java的设计中，每一个Java对象就带了一把看不见的锁，可以叫做内部锁或者Monitor锁，Synchronized在JVM里的实现是基于进入和退出Monitor对象来实现方法同步和代码块同步的。Monitor可以把它理解为一个同步工具，所有的Java对象是天生的Monitor，Monitor监视器对象就是存在于每个Java对象的对象头MarkWord里面，也就是存储指针的指向，Synchronized锁便是通过这种方式获取锁的。

JDK6以前

Synchronized加锁是通过对象内部的监视器锁来实现的，监视器锁本质又是依赖于底层的操作系统的Mutex Lock来实现的，操作系统实现线程之间的切换这就需要从用户态转换到核心态，这个成本非常高，状态之间的转换需要比较长的时间。

实现步骤

第一步，当有二个线程A、线程B都要开始给变量+1，要进行操作的时候，发现方法上加了Synchronized锁，这时线程调度到A线程执行，A线程就抢先拿到了锁，当前已经获取到锁资源的线程被称为Owner，将MonitorObject中的_owner设置成A线程。

第二步，将mark word设置为Monitor对象地址，锁标志位改为10；

第三步，将B线程阻塞，放到ContentionList队列中。因为JVM每次从Waiting Queue的尾部取出一个线程放到OnDeck中，作为候选者，但是如果并发比较高，WaitingQueue会被大量线程执行CAS操作，为了降低对尾部元素的竞争，将WaitingQueue拆分成ContentionList和EntryList二个队列，所有请求锁的线程首先尝试自旋获取锁，如果获取不到，被放在ContentionList这个竞争队列中，ContentionList中那些有资格成为候选资源的线程被移动到EntryList中。ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，该阻塞是由操作系统来完成的，Linux内核下采用pthread_mutex_lock内核函数实现的。

第四步，作为Owner的A线程执行过程中，可能调用wait释放锁，这个时候A线程进入WaitSet，等待被唤醒。

JDK6版本及以后

Sun程序员发现大部分程序大多数时间都不会发生多个线程同时访问竞态资源的情况，大多数对象的加锁和解锁都是在特定的线程中完成，出现线程竞争锁的情况概率比较低，比例非常高，所以引入了偏向锁和轻量级锁。

64位JVM下的对象结构描述：
对象头的最后两位存储了锁的标志位
没加锁状态，锁标志位01，是否偏向是0，对象头里存储的是对象本身的哈希码。
偏向锁状态，锁标志位01，是否偏向是1，存储的是当前占用对象的线程ID。
轻量级锁状态，锁标志位00，存储指向线程栈中锁记录的指针。
重量级锁状态，锁标志位10，存储的就是重量级锁的指针了。

对象从无锁到偏向锁转化的过程

第一步，检测MarkWord是否为可偏向状态，是偏向锁是1，锁标识位是01。
第二步，如果是可偏向状态，测试线程ID是不是当前线程ID。如果是，就直接执行同步代码块。
第三步，如果测试线程ID不是当前线程ID，就通过CAS操作竞争锁，竞争成功，就把MarkWord的线程ID替换为当前线程ID。
第四步，如果CAS竞争锁失败，证明有别的线程持有锁，假设线程B来CAS失败了，这个时候启动偏向锁撤销（revokebias），让A线程在全局安全点阻塞，获得偏向锁的线程被挂起，有点类似于GC前线程在安全点阻塞。
第五步，接着遍历线程栈，查看有没有锁对象的锁记录LockRecord，如果有LockRecord，需要修复锁记录和Markword，让它变成无锁状态。恢复A线程，将是否为偏向锁状态改为0，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程，继续往下执行同步代码块。

安全点是jvm为了保证在垃圾回收的过程中引用关系不会发生变化，设置的安全状态，在这个状态上会暂停所有线程工作。一般有循环的末尾，方法临返回前，调用方法的call指令后，可能抛异常的位置，这些位置都可以算是安全点。

轻量级锁升级

轻量级锁升级过程是，在当前线程的栈帧中建立一个名为锁记录的空间，用于存储锁对象目前的MarkWord的拷贝，拷贝无锁状态对象头中的MarkWord复制到锁记录中。

• 这么做是因为在申请对象锁时，需要以该值作为CAS的比较条件。
• 同时在升级到重量级锁的时候，能通过这个比较，判定是否在持有锁的过程中，这个锁被其他线程申请过，如果被其他线程申请了，在释放锁的时候要唤醒被挂起的线程。
• 无锁的markword中可能存有hashCode，锁撤销之后必须恢复，这个markword要用于锁撤销后的还原。如果轻量级锁解锁为无锁状态，直接将拷贝的markword CAS修改到锁对象的markword里面就可以了。

拷贝成功后，虚拟机将使用CAS操作把对象中对象头MarkWord替换为指向锁记录的指针，然后把锁记录空间里的owner指针指向加锁的对象，如果这个更新动作成功了，那么当前线程就拥有了该对象的锁，并且对象MarkWord的锁标志位设置为“00”，即表示此对象处于轻量级锁定状态。

如果这个更新操作失败了，虚拟机首先会检查对象MarkWord中的Lock Word是否指向当前线程的栈帧，如果是，就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。如果不是说明多个线程竞争锁，进入自旋，若自旋结束时仍未获得锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为“10”，MarkWord中存储的就是指向重量级锁（互斥量）的指针，当前线程以及后面等待锁的线程也要进入阻塞状态。

当锁升级为轻量级锁之后，如果依然有新线程过来竞争锁，首先新线程会自旋尝试获取锁，尝试到一定次数（默认10次）依然没有拿到，锁就会升级成重量级锁。一般来说，同步代码块内的代码应该很快就执行结束，这时候线程B自旋一段时间是很容易拿到锁的，但是如果不巧，没拿到，自旋其实就是死循环，很耗CPU的，因此就直接转成重量级锁咯，这样就不用了线程一直自旋了。

自旋锁

自旋锁不是一种锁状态，而是一种策略。线程的阻塞和唤醒需要CPU从用户态转为核心态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作。

引入自旋锁，当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是进入线程挂起或睡眠状态。自旋等待不能替代阻塞，虽然它可以避免线程切换带来的开销，但是它占用了CPU处理器的时间。

自旋锁适用于锁保护的临界区很小的情况，临界区很小的话，锁占用的时间就很短。如果持有锁的线程很快就释放了锁，那么自旋的效率就非常好。

自旋的次数必须要有一个限度，如果自旋超过了定义的限度仍然没有获取到锁，就应该被挂起。但是这个限度不能固定，程序锁的状况是不可预估的，所以JDK1.6引入自适应的自旋锁，线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。如果对于某个锁，很少有自旋能够成功，那么在以后要或者这个锁的时候自旋的次数会减少，甚至省略掉自旋过程，以免浪费处理器资源。

通过–XX:+UseSpinning参数来开启自旋（JDK1.6之前默认关闭自旋）。
通过–XX:PreBlockSpin修改自旋次数，默认值是10次。

重量级锁

当一个线程在等锁时会不停的自旋（底层就是一个while循环），当自旋的线程达到CPU核数的1/2时，就会升级为重量级锁。

将锁标志为置为10，将MarkWord中指针指向重量级的monitor，阻塞所有没有获取到锁的线程。

Synchronized是通过对象内部的监视器锁（Monitor）来实现的，监视器锁本质又是依赖于底层的操作系统的MutexLock来实现的，操作系统实现线程之间的切换这就需要从用户态转换到核心态，状态之间的转换需要比较长的时间，这就是为什么Synchronized效率低的原因，这种依赖于操作系统MutexLock所实现的锁我们称之为“重量级锁”。

重量级锁的加锁-等待-撤销流程：
曾经获得过锁的线程，被唤醒后，优先得到锁。

举个例子，假设有A，B，C三个线程依次进入synchronized区，并且A已经膨胀成重量级锁。如果有一个线程 a 先进入 synchronized , 但是调用了 wait释放锁，这是线程 b 进入了 synchronized，b还在synchronized中执行，c线程又进来了。此时 a 在 wait_set ，b 不在任何队列，c 在 cxq_list ，假如 b 调用 notify唤醒线程，会把 a 插到 c 前面，也就是 b 退出synchronized的时候，会唤醒 a，a退出之后再唤醒 c。

重量级锁撤销之后是无锁状态，撤销锁之后会清除创建的monitor对象并修改markword，这个过程需要一段时间。Monitor对象是通过GC来清除的。GC清除掉monitor对象之后，就会撤销为无锁状态。

引入偏向锁的好处

• 偏向锁的好处是并发度很低的情况下，同一个线程获取锁不需要内存拷贝的操作，免去了轻量级锁的在线程栈中建LockRecord，拷贝MarkDown的内容。

• 免了重量级锁的底层操作系统用户态到内核态的切换，节省毫无意义的请求锁的时间。

• 另外Hotspot也做了另一项优化，基于锁对象的epoch批量偏移和批量撤销偏移，这样大大降低了偏向锁的CAS和锁撤销带来的损耗。因为基于epoch批量撤销偏向锁和批量加偏向锁能大幅提升吞吐量，但是并发量特别大的时候性能就没有什么特别的提升了。

• 偏向锁减少CAS操作，降低Cache一致性流量，CAS操作会延迟本地调用。

为什么这么说呢？这要从SMP（对称多处理器）架构说起，所有的CPU会共享一条系统总线BUS，靠此总线连接主内存，每个核都有自己的一级缓存，每个核相对于BUS对称分布。
举个例子，我电脑是六核的，假设一个核是Core1，一个核是Core2，这二个核可能会同时把主存中某个位置的值Load到自己的一级缓存中。当Core1在自己的L1Cache中修改这个位置的值时，会通过总线，使Core2中L1Cache对应的值“失效”，而Core2一旦发现自己L1Cache中的值失效，也就是所谓的Cache命中缺失，一旦发现失效就会通过总线从内存中加载该地址最新的值，大家通过总线的来回通信叫做“Cache一致性流量”。如果Cache一致性流量过大，总线将成为瓶颈。而当Core1和Core2中的值再次一致时，称为“Cache一致性”，从这个层面来说，锁设计的终极目标便是减少Cache一致性流量。而CAS恰好会导致Cache一致性流量，如果有很多线程都共享同一个对象，当某个CoreCAS成功时必然会引起总线风暴，这就是所谓的本地延迟。

所以偏向锁比较适用于只有一个线程访问同步块场景。

引入轻量级的好处

对于绝大部分的锁，在整个同步周期内都是不存在竞争的。如果没有竞争，轻量级锁通过CAS操作成功，避免了使用互斥量的开销。

对于竞争的线程不会阻塞，提高了程序的响应速度。

如果确实存在锁竞争，始终得不到锁竞争的线程使用自旋会消耗CPU，除了互斥量的本身开销外，还额外发生了CAS操作的开销，轻量级锁反而会比传统的重量级锁更慢。

所以轻量级追求的是响应时间，同步块执行速度非常快的场景。

ThreadLocal

定义

ThreadLocal叫做线程变量，这个变量对其他线程而言是隔离的，是当前线程独有的变量。ThreadLocal为变量在每个线程中都创建了一个副本，每个线程可以访问自己内部的副本变量。

ThreadLocal与Synchronized的区别

1、Synchronized用于线程间的数据共享，ThreadLocal用于线程间的数据隔离。

2、Synchronized是利用锁的机制，让变量或代码块在某一时该只能被一个线程访问，用于在多个线程间通信时能够获得数据共享。ThreadLocal为每一个线程都提供了变量的副本，让每个线程在某一时间访问到的并不是同一个对象，这样就隔离了多个线程对数据的数据共享。

底层实现

在 Thread 类中嵌入一个 ThreadLocalMap，ThreadLocalMap 就是一个容器，存储的就是这个 Thread 类专享的数据。

ThreadLocalMap底层结构

static class ThreadLocalMap {

        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
        ……
    }    

ThreadLocal在保存的时候会把自己当做Key存在ThreadLocalMap中，key被设计成WeakReference弱引用了。

ThreadLocalMap的key设计成弱引用，主要是为了避免内存泄漏的情况。如果 threadlocalmap 的 key 是强引用, 那么只要线程存在, threadlocalmap 就存在, 而 threadlocalmap 结构就是 entry 数组. 即对应的 entry 数组就存在, 而 entry 数组元素的 key 是 threadLocal.即便我们在代码中显式赋值 threadlocal 为 null, 告诉 gc 要垃圾回收该对象. 由于上面的强引用存在, threadlocal 即便赋值为 null, 只要线程存在, threadlocal 并不会被回收。

而设置为弱引用, gc 扫描到时, 发现ThreadLocal在没有外部强引用时，发生GC时会被回收，如果创建ThreadLocal的线程一直持续运行，那么这个Entry对象中的value就有可能一直得不到回收，发生内存泄露。所以在代码最后都需要用remove把值清空。

remove的源码很简单，找到对应的值全部置空，这样在垃圾回收器回收的时候，会自动把他们回收掉。

并且 threadlocal 的 set get remove 都会判断是否 key 为 null, 如果为 null, 那么 value 的也会移除, 之后会被 gc 回收。

结构大致这样：

ThreadLocalMap存储元素的过程

ThreadLocalMap在存储的时候会给每一个ThreadLocal对象一个threadLocalHashCode，在插入过程中，根据ThreadLocal对象的hash值，定位到table中的位置，如果当前位置是空的，就初始化一个Entry对象放在位置上。如果位置不为空，如果这个Entry对象的key正好是即将设置的key，那么就刷新Entry中的value。如果位置不为空，而且key不等于entry，那就找下一个空位置，直到为空为止。在get的时候，也会根据ThreadLocal对象的hash值，定位到table中的位置，然后判断该位置Entry对象中的key是否和get的key一致，如果不一致，就判断下一个位置。这种方式在不使用链表的情况下，解决了hash冲突。

ThreadLocal实现线程隔离的原理

ThreadLocal实现线程隔离主要是设置值和获取值的时候，就已经保证了它是线程隔离了。
设置值的代码：

public void set(T value) {
    Thread t = Thread.currentThread();// 获取当前线程
    ThreadLocalMap map = getMap(t);// 获取ThreadLocalMap对象
    if (map != null) // 校验对象是否为空
        map.set(this, value); // 不为空set
    else
        createMap(t, value); // 为空创建一个map对象
}

设置值先是获取当前线程对象，然后从当前线程中获取线程的ThreadLocalMap，判断这个对象是不是空的，如果是空的，就创建一个空的map对象，如果不为空，就重新设值。key就是当前ThreadLocal 的对象，值是添加到这个ThreadLocalMap中的，它是存储在线程内部，然后关联了对应的ThreadLocal。

ThreadLocalMap是当前线程Thread一个叫threadLocals的变量中获取的

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

public class Thread implements Runnable {
      ……

    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

    /*
     * InheritableThreadLocal values pertaining to this thread. This map is
     * maintained by the InheritableThreadLocal class.
     */
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
     ……

每个线程Thread都维护了自己的threadLocals变量，所以在每个线程创建ThreadLocal的时候，实际上数据是存在自己线程Thread的threadLocals变量里面的，别人没办法拿到，从而实现了隔离。

通过ThreadLocal.get 时就能获取到对应的值。

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T)e.value;
            return result;
        }
    }
    return setInitialValue();
}

AQS

AQS的全称是AbstractQueuedSynchronizer，也就是抽象队列同步器，它是在java.util.concurrent.locks包下的，也就是JUC并发包。java提供了synchronized关键字内置锁，还提供了显示锁，而大部分的显示锁的底层都用到了AQS，比如只有一个线程能执行ReentrantLock独占锁，又比如多个线程可以同时执行共享锁Semaphore、CountDownLatch、ReadWriteLock、CyclicBarrier。

同步器自身没有实现任何同步接口，它仅仅是定义了同步状态获取和释放的方法，提供自定义同步组件使用，子类通过继承同步器，实现它的抽象方法来管理同步状态。使用模板方法模式，使用者继承AbstractQueuedSynchronizer，重写指定的方法，重写的方法就是对于共享资源state的获取和释放，在自定义同步组件里调用它的模板方法，这些模板方法会调用使用者重写的方法，这是模板方法模式很经典的一个运用。

同步器依赖内部的一个FIFO双向同步队列来完成同步状态的管理，当前线程获取同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点并将其加入同步队列，同时会阻塞当前线程。当同步状态释放时，会把首节点中的线程唤醒，使其再次尝试获取同步状态。

同步器拥有首节点和尾节点，首节点是获取同步状态成功的节点，首节点的线程在释放同步状态时，将会唤醒后继节点， 而后继节点将会在获取同步状态成功时将自己设置为首节点，没有成功获取同步状态的线程会成为节点，加入该队列的尾部。

独占锁举例

拿ReentrantLock加锁举例，线程调用ReentrantLock的lock()方法进行加锁，这个加锁的过程，用CAS将state值从0变为1。一旦线程加锁成功了之后，就可以设置当前加锁线程是自己。ReentrantLock通过多次执行lock()加锁和unlock()释放锁，对一个锁加多次，从而实现可重入锁，每次线程可重入加锁一次，判断一下当前加锁线程是不是自己，如果是他自己就可以可重入多次加锁，每次加锁，就是把state的值给累加1。

当state=1时代表当前对象锁已经被占用，其他线程来加锁时则会失败，然后再去看加锁线程的变量里面是不是自己之前占用过这把锁，如果不是就说明有其他线程占用了这个锁，失败的线程被放入一个等待队列中，在等待唤醒的时候，经常会使用自旋（while(!cas())）的方式，不停地尝试获取锁，等待已经获得锁的线程，释放锁才能被唤醒。

当它释放锁的时候，将AQS内的state变量的值减1，如果state值为0，就彻底释放锁，会将“加锁线程”变量设置为null。这个时候，会从等待队列的队头唤醒其他线程重新尝试加锁，获得锁成功之后，会把“加锁线程”设置为线程自己，同时线程自己就从等待队列中出队。

底层实现独占锁

public final void acquice(int arg){
	//同步状态获取、节点构造、加入同步队列以及在同步队列中自旋等待
	if(!tryAcquirce(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE),arg)){
		selfInterrupt();
	}
}

首先调用自定义同步器实现的tryAcquire方法，保证线程安全的获取同步状态。
如果同步状态获取成功直接退出返回。
如果同步状态获取失败，就构造同步节点，通过addWaiter方法把这个节点加入到同步队列的尾部。
最后调用acquireQueued方法，让节点自旋的获取同步状态。

这个就是aqs实现独占锁的底层实现。

超时获取锁

在Java 5之前，当一个线程获取不到锁而被阻塞在synchronized之外时，对该线程进行中断操作，此时这个线程的中断标志位会被修改，但线程依旧会阻塞在synchronized上，等待着获取锁。

Java 5中，在等待获取同步状态时，如果当前线程被中断，会立刻返回，并抛出InterruptedException。

后续的版本又进行了优化，提供了超时获取同步状态过程，可以被当作响应中断，是获取同步状态过程的“增强版”， doAcquireNanos方法在支持响应中断的基础上，增加了超时获取的特性。

针对超时获取，主要需要计算出需要睡眠的时间间隔nanosTimeout，为了防止过早通知， nanosTimeout计算公式为：
nanosTimeout = now-lastTime，其中now为当前唤醒时间，lastTime为上次唤醒时间。
如果 nanosTimeout大于0则表示超时时间未到，需要继续睡眠nanosTimeout纳秒， 否则，表示已经超时。
如果nanosTimeout小于等于1000纳秒时， 将不会使该线程进行超时等待，而是进入快速的自旋过程。

原因在于，非常短的超时等待，无法做到十分精确，如果这时再进行超时等待，相反会让nanosTimeout的超时从整体上表现得反而不精确。因此，在超时非常短的场景下，同步器会进入无条件的快速自旋。

共享锁举例

拿CountDownLatch举例，任务分为5个子线程去执行，state也初始化为5。这5个子线程是并行执行的，每个子线程执行完后countDown()一次，state会CAS减1，等到所有子线程都执行完后，state=0，会unpark()主调用线程，然后主调用线程就会从await()函数返回，继续后余动作。

共享锁实现原理

共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状态。通过调用同步器的acquireShared方法可以共享式地获取同步状态，只要方法里面的tryAcquireShared方法返回值大于等于0，就可以成功获取到同步状态并退出自旋。对于能够支持多个线程同时访问的并发组件，它和独占式主要区别在于 tryReleaseShared方法必须确保同步状态线程安全释放，一般是通过循环和CAS来保证的，因为释放同步状态的操作可能会同时来自多个线程。

AQS为什么要使用双向链表

首先，双向链表的特点是它有两个指针，一个指针指向前置节点，一个指针指向后继节点。

所以，双向链表可以支持 常量O(1) 时间复杂度的情况下找到前驱结点，基于这样的特点。

双向链表在插入和删除操作的时候，要比单向链表简单、高效。

因此，从双向链表的特性来看，我认为AQS使用双向链表有三个方面的考虑。

• 第一个方面，没有竞争到锁的线程加入到阻塞队列，并且阻塞等待的前提是，当前线程所在节点的前置节点是正常状态，

  这样设计是为了避免链表中存在异常线程导致无法唤醒后续线程的问题。

  所以线程阻塞之前需要判断前置节点的状态，如果没有指针指向前置节点，就需要从head节点开始遍历，性能非常低。
  

• 第二个方面，在Lock接口里面有一个，lockInterruptibly()方法，这个方法表示处于锁阻塞的线程允许被中断。也就是说，没有竞争到锁的线程加入到同步队列等待以后，是允许外部线程通过interrupt()方法触发唤醒并中断的。
  这个时候，被中断的线程的状态会修改成CANCELLED。被标记为CANCELLED状态的线程，是不需要去竞争锁的，但是它仍然存在于双向链表里面。意味着在后续的锁竞争中，需要把这个节点从链表里面移除，否则会导致锁阻塞的线程无法被正常唤醒。在这种情况下，如果是单向链表，就需要从Head节点开始往下逐个遍历，找到并移除异常状态的节点。同样效率也比较低，还会导致锁唤醒的操作和遍历操作之间的竞争。
  

• 第三个方面，为了避免线程阻塞和唤醒的开销，所以刚加入到链表的线程，首先会通过自旋的方式尝试去竞争锁。但是实际上按照公平锁的设计，只有头节点的下一个节点才有必要去竞争锁，后续的节点竞争锁的意义不大。否则，就会造成羊群效应，也就是大量的线程在阻塞之前尝试去竞争锁带来比较大的性能开销。所以为了避免这个问题，加入到链表中的节点在尝试竞争锁之前，需要判断前置节点是不是头节点，如果不是头节点，就没必要再去触发锁竞争的动作。所以这里会涉及到前置节点的查找，如果是单向链表，那么这个功能的实现会非常复杂。
  

线程池

底层运行原理

线程池就是控制运行的线程数量，处理过程中将任务放到队列，然后在线程创建后启动这些任务，如果线程数量超出了最大数量就排队等候，等其他线程执行完毕再从队列中取出任务执行。

线程池相当于银行网点，常驻核心数相当于今日当值窗口，线程池能够同时执行的最大线程数相当于银行所有的窗口，任务队列相当于银行的候客区，当今日当值窗口满了，多出来的客户去候客区等待，当候客区满了，银行加开窗口，候客区先来的客户去加班窗口，当银行所有的窗口满了，其他客户在候客区等待，同时拒绝其他客户进入银行。当用户少了，加班的窗口等待时间（相当于多余线程存活的时间）（等待时间的单位相当于unit参数）假设超过一个小时还是没有人来，就取消加班的窗口。

七大核心参数

底层在创建线程池的时候有七个参数：核心线程数，同时执行的最大线程数，多余线程存活时间，单位时间秒，任务队列，默认线程工厂，拒绝策略

maximumPoolsize：同时执行的最大线程数
keepAliveTime：多余线程存活时间，当前线程池数量超过核心线程数时，当前空闲时间达到多余线程存活时间的值的时候，多余空闲线程会被销毁到只剩核心线程数为止
unit：多余线程存活时间的单位
workQueue：任务队列，被提交但尚未被执行的任务
threadFactory：生成线程池的线程工厂
handler：拒绝策略，当队列满了并且工作线程数量大于线程池的最大线程数时，提供拒绝策略。

如何合理的配置核心线程数？

对于CPU密集型任务，由于CPU密集型任务的性质，导致CPU的使用率很高，如果线程池中的核心线程数量过多，会增加上下文切换的次数，带来额外的开销。因此，考虑到CPU密集型任务因为某些原因而暂停，这个时候有额外的线程能确保CPU这个时刻不会浪费，还可以增加一个CPU上下文切换。一般情况下：线程池的核心线程数量等于CPU核心数+1。例如需要大量的计算，视频渲染啊，仿真啊之类的。这个时候CPU就卯足了劲在运行，这个时候切换线程，反而浪费了切换的时间，效率不高。打个比方，你的大脑是CPU，你本来就在一本心思地写作业，多线程这时候就是要你写会作业，然后立刻敲一会代码，然后在P个图，然后在看个视频，然后再切换回作业。emmmm，过程中你还需要切换（收起来作业，拿出电脑，打开VS…）那你的作业怕是要写到挂科。这个时候你就该一门心思地写作业。

对于I/O密集型任务，由于I/O密集型任务CPU使用率并不是很高，可以让CPU在等待I/O操作的时去处理别的任务，充分利用CPU。一般情况下：线程的核心线程数等于2*CPU核心数。例如你需要陪小姐姐或者小哥哥聊天，还需要下载一个VS，还需要看博客。打个比方，小姐姐给你发消息了，回一下她，然后呢？她给你回消息肯定需要时间，这个时候你就可以搜索VS的网站，先下安装包，然后一看，哎呦，她还没给你回消息，然后看会自己的博客。小姐姐终于回你了，你回一下她，接着看我的博客，这就是类似于IO密集型。你可以在不同的“不烧脑”的工作之间切换，来达到更高的效率。而不是小姐姐不回我的信息，我就干等，啥都不干，就等，这个效率可想而知，也许，小姐姐根本就不会回复你。

对于混合型任务，由于包含2种类型的任务，故混合型任务的线程数与线程时间有关。在某种特定的情况下还可以将任务分为I/O密集型任务和CPU密集型任务，分别让不同的线程池去处理。一般情况下：线程池的核心线程数=(线程等待时间/线程CPU时间+1)*CPU核心数；

并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，我们的项目使用的时redis作为缓存（这类非关系型数据库还是挺好的）。增加服务器是第二步（一般政府项目的首先，因为不用对项目技术做大改动，求一个稳，但前提是资金充足），至于线程池的设置，设置参考 2 。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件（任务时间过长的可以考虑拆分逻辑放入队列等操作）对任务进行拆分和解耦。

拒绝策略

第一种拒绝策略：AbortPolicy：超出最大线程数，直接抛出RejectedExecutionException异常阻止系统正常运行。可以感知到任务被拒绝了，于是你便可以根据业务逻辑选择重试或者放弃提交等策略。

第二种拒绝策略：该策略既不会抛弃任务，也不会抛出异常，而是将某些任务回退到调用者，相当于当线程池无能力处理当前任务时，会将这个任务的执行权交予提交任务的线程来执行，也就是谁提交谁负责，从而降低新任务的流量。（谁调用了你，到达最大线程数时，你回去找调用你的人，然后听从调用你的人安排）（超出的我们能办的给你办，不能办的给你回退 ）这样的话提交的任务就不会被丢弃而造成业务损失，如果任务比较耗时，那么这段时间内提交任务的线程也会处于忙碌状态而无法继续提交任务，这样也就减缓了任务的提交速度，这相当于一个负反馈，也有利于线程池中的线程来消化任务。这种策略算是最完善的相对于其他三个。

第三拒绝策略：DiscardOldestPolicy:抛弃队列中等待最久的任务，也就是它丢弃的是队列中的头节点，然后把当前任务加入队列中尝试再次提交当前任务。

第四种拒绝策略：DiscardPolicy:直接丢弃任务，不予任何处理也不抛异常，当任务提交时直接将刚提交的任务丢弃，而且不会给与任何提示通知。

实际创建线程池

java.util.concurrent 包里提供的 Executors 也可以用来创建线程池

• newSingleThreadExecutos 单线程线程池，也就是线程池只有一个任务，这个我偶尔用一用
• newFixedThreadPool(int nThreads) 固定大小线程的线程池
• newCachedThreadPool() 无界线程池，这个就是无论多少任务，都创建线程来运行，所以队列相当于没用。

在实际使用的时候，选择线程池的时候尽量不用JDK提供的三种常见的创建方式
第一是 Executors 提供的线程池使用场景很有限，一般场景很难用到
第二他们也都是通过 ThreadPoolExecutor 创建的线程池，我直接用 ThreadPoolExecutor 创建线程池，可以理解原理，灵活度更高。
第三因为它的底层队列是Linked这个接近于无界，非常大，这样会堆积大量的请求，从而导致OOM，阿里巴巴开发手册推荐我们使用ThreadPoolExecutor去创建线程池。

内存模型

JDK1.6、JDK1.7、JDK1.8 内存模型演变

JDK 1.6：有永久代，静态变量存放在永久代上。
JDK 1.7：有永久代，但已经把字符串常量池、静态变量，存放在堆上。逐渐的减少永久代的使用。
JDK 1.8：无永久代，运行时常量池、类常量池，都保存在元数据区，也就是常说的元空间。但字符串常量池仍然存放在堆上。

Java虚拟机栈

每一个方法在执行的同时，都会创建出一个栈帧，用于存放局部变量表、操作数栈、动态链接、方法出口、线程等信息。方法从调用到执行完成，都对应着栈帧从虚拟机中入栈和出栈的过程。最终，栈帧会随着方法的创建到结束而销毁。

堆和元空间

在 JDK 1.8 之后就不在堆上分配方法区了，元空间从虚拟机Java堆中转移到本地内存，默认情况下，元空间的大小仅受本地内存的限制，说白了也就是以后不会因为永久代空间不够而抛出OOM异常出现了。jdk1.8以前版本的 class和JAR包数据存储在 PermGen下面 ，PermGen 大小是固定的，而且项目之间无法共用，公有的 class，所以比较容易出现OOM异常。

内存屏障

什么是内存屏障：内存屏障是一条指令，该指令可以对编译器和处理器的指令重排做出一定的限制，比如，一条内存屏障指令可以禁止编译器和处理器将其后面的指令移到内存屏障指令之前。

为什么需要内存屏障：编译器和处理器指令重排只能保证在单线程执行下逻辑正确，在多个线程同时读写多个变量的情况下，如果不对指令重排作出一定限制，代码的执行结果会根据指令重排后的顺序产生不同的结果。指令重排后的顺序每次执行时都可能不一样，显然我们希望我们的代码执行结果与代码顺序是逻辑一致的，所以我们需要内存屏障。

Class文件结构

字节码结构有：魔数，副版本号，主版本号，常量池容量计数器，访问标志，类索引，父类索引，接口索引集合，字段表，方法表，属性表等。

拿魔数来说，它是用来区分文件类型的一种标志，会占用开头的4个字节，之所以需要魔数来区分文件类型，是因为文件名后缀容易被修改，所以为了保证文件的安全性，将文件类型写在文件内部可以保证不被篡改。

魔数后面的4位就是版本号，也是4个字节，前2个字节表示次版本号，后2个字节表示主版本号，这二个版本号是为了标注jdk的一个版本，起到一个jdk版本兼容性的一个作用，比如说高版本的jdk代码不能使用低版本的jdk运行，这个时候主次版本号就起到这个作用。

版本号后二个字节就是常量池容量计数器，写代码时都是从0开始的，但是这里的常量池却是从1开始，因为它把第0项常量空出来了，这是为了满足不引用任何一个常量池的项目，比如说匿名内部类，它没有类名，但是它的类名也需要存储到常量池里面，那只能指向常量池的第0号位置，又比如说Object类，它是所有类的父类，那它的父类指向的是常量池中的0的位置。

常量池后面就是访问标志，用两个字节来表示，其标识了类或者接口的访问信息，比如：这个.Class文件是类还是接口，是不是被定义成public，是不是abstract，如果是类，是不是被声明成final等。

访问标志后的两个字节就是类索引，通过类索引我们可以确定到类的全限定名。类索引后的两个字节就是父类索引，通过父类索引可以确定到父类的全限定名，通过这二个全限定名可以获取到类路径。

父类索引后的两个字节是接口索引计数器，接口索引计数器表示接口索引集合中接口的数量。

接口索引计数器后边二个字节是接口索引集合，它是按照当前类实现的接口顺序，从左到右依次排列在接口索引集合中。

接口索引集合后边二个字节是字段表计数器，用来表示字段表的容量，字段表计数器后边是字段表。我们知道，一个字段可以被各种关键字去修饰，比如：作用域修饰符（public、private、protected）、static修饰符、final修饰符、volatile修饰符等，所以也可以像类的访问标志那样，使用一些标识来标记字段。字段表作为一个表，同样他也有自己的结构，比如说访问标志，字段名索引，描述符索引，属性计数器，属性集合。在Java语言中字段是无法重载的，两个字段的数据类型，修饰符不管是否相同，都必须要有不一样的名称，但是对于字节码文件来说，如果两个字段的描述符不一致，那这二个字段重名就是合法的。

字段表后边二个字节是方法表计数器，表示方法表的容量，方法表计数器后边紧跟的是方法表。

和字段表类似，方法表里面也有自己的结构，比如说访问标志，方法名索引，描述符索引，属性计数器，属性集合。

方法表后边紧跟的是属性表计数器，属性表计数器后边紧跟的结构为属性表。

属性表的两大特点：一个是限制比较宽松，没有顺序长度要求；一个是开发者可以根据自己的需求，向属性表中添加不重复的属性。

类加载机制和双亲委派机制

第一步，加载，一个Java源文件进行编译之后，成为一个class字节码文件存储在磁盘上面，这个时候jvm需要读取这个字节码文件，通过通过IO流读取字节码文件，这一步就是加载。

类加载器将.class文件加载到JVM，首先是看当前类是不是使用自定义加载类加载的，如果不是，就委派应用类加载器加载，如果有加载过这个class文件，那就不用再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类的扩展类加载器同理也会先检查自己是不是已经加载过，如果没有再往上，看看启动类加载器。到启动类加载器，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己加载不了，就会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException找不到类异常，这就是所谓的双亲委派机制。
这种机制可以避免，同路径下的同文件名的类，比如，自己写了一个java.lang.obejct，这个类和jdk里面的object路径相同，文件名也一样，这个时候，如果不使用双亲委派机制的话，就会出现不知道使用哪个类的情况，而使用了双亲委派机制，它就委派给父类加载器就找这个文件是不是被加载过，从而避免了上面这种情况的发生。

第二步，验证，JVM读到文件也不是直接运行，还需要校验加载进来的字节码文件是不是符合JVM规范

1. 验证的第一步就是文件的格式验证，验证class文件里面的魔数和主次版本号，发现它是一个jvm可以支持的class文件并且它的主次版本号符合兼容性要求，所以验证通过。

2. 然后又回到了加载，它会将class文件这个二进制静态文件转化到方法区里面，转化为方法区的时候，会有一个结构的调整，将静态的存储文件转化为运行时数据区，这个转化等于说又回到了加载。

3. 接着到了方法区的运行时数据区以后，在java堆内存里面生成一个当前类的class对象，作为方法区里面这个类，被各种访问的一个入口。比如说object类，它是所有类都继承它，访问它，所以它也需要一个被各种类访问的入口。object类先加载，加载完成之后，它经过这一系列的操作，把自己java.lang.object放到这个堆里面，要让其他的类进行访问，这个也是加载。

4. 接着到了验证里面的第二步元数据验证，它会对字节码描述的信息进行语义分析，比如：这个类是不是有父类，是不是实现了父类的抽象方法，是不是重写了父类的final方法，是不是继承了被final修饰的类等等。

5. 第三步，字节码验证，通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，比如：操作数栈的数据类型与指令代码序列是不是可以配合工作，方法中的类型转换是不是有效等等。

6. 第四步，符号引用验证：确保解析动作可以正确执行，比如说：通过符号引用是不是可以找到对应的类和方法，符号引用中类、属性、方法的访问性是不是能被当前类访问等，验证完成之后，需要做准备。

准备就是给类的静态变量分配内存，并赋予默认值。我们的类里，可能会包含一些静态变量， 比如说public static int a = 12; 得给a这个变量分配个默认值 0，再比如public static User user = new User(); 给 static的变量User分配内存，并赋默认值null。如果是final修饰的常量，就不需要给默认值了，直接赋值就可以了。

然后就是解析，解析就是将符号引用变为直接引用，该阶段会把一些静态方法替换为指向数据储存在内存中的指针或者句柄，也就是所谓的直接引用，这个就是静态链接过程，是在初始化之前完成。有静态链接就有动态链接，动态链接是在程序运行期间完成将符号引用替换为直接引用，比如静态方法里面有个方法，在运行的时候，方法是存放在常量池中的符号，运行到这个符号，就是找这个符号对应的方法区，因为代码的指令是加载到方法区里面去的，最后把方法对应代码的地址放到栈帧中的动态链接里。

后面就是初始化了，初始化就是对类的静态变量初始化为指定的值并且会执行静态代码块。比如准备阶段的public static final int a = 12;这个变量，就是准备阶段给static变量a赋了默认值0，这一步就该把12赋值给它了。还有static的User public static User user = new User(); 把User进行实例化。

最后就是使用和卸载了，到此整个加载流程就走完了。

垃圾回收器、垃圾回收算法、空间分配担保

垃圾回收器有多个，先说新生代的三个垃圾回收器，serial，parnew，parallel scavenge，然后再说老年代的serial old，parallel old，cms，最后在说一下新生代和老年代都使用的垃圾回收器G1吧。

Serial

Serial是新生代下使用复制算法，单线程运行的垃圾回收器，简单高效，没有线程交互开销，专注于GC，这个垃圾回收器工作的时候会将所有应用线程全部冻结，而且是单核cpu，所以基本不会考虑使用它。

ParNew

ParNew是新生代下使用复制算法，多线程运行的垃圾回收器，可以并行并发GC，和serial对比，除了多核cpu并行gc其他基本相同。

Parallel scavenge

Parallel scavenge也是新生代下使用复制算法，可以进行吞吐量控制的多线程回收器，主要关注吞吐量，通过吞吐量的设置控制停顿时间，适应不同的场景。可以发现新生代的垃圾回收器都使用，复制算法进行gc。

复制算法

新生代中每次垃圾回收都要回收大部分对象，所以为了避免内存碎片化的缺陷，这个算法按内存容量将内存划分为大小相等的两块，每次只使用其中一块，当这一块存活区内存满后将gc之后还存活的对象复制到另一块存活区上去，把已使用的内存清掉。

分代收集算法

按照分代收集算法的思想，把应用程序可用的堆空间分为年轻代，老年代，永久代，然后年轻代有被分为Eden区和二个Survivor存活区，这个比例又可以分为8比1比1。当第一次eden区发生minor gc，会把存活的对象复制到其中的一个Survivor区，然后eden区继续放对象，直到触发gc，会把eden区和之前存放对象的Survivor区一起gc，二个区存活下来的对象，复制到另一个空的Survivor里面，这二个区就清空，然后将二个存活区角色互换。

进入老年代的几种情况

当对象在Survivor区躲过一次GC 后，年龄就会+1，存活的对象在二个Survivor区不停的移动，默认情况下年龄到达15的对象会被移到老生代中，这是对象进入到老年代的第一种情况。

这里就会有个问题，JVM分代年龄为什么是15次？
一个对象的GC年龄，是存储在对象头里面的，一个Java对象在JVM内存中的布局由三个部分组成，分别是对象头、实例数据、对齐填充。而对象头里面有4个bit位来存储GC年龄。

4个bit位能够存储的最大数值是15，所以从这个角度来说，JVM分代年龄之所以设置成15次是因为它最大能够存储的数值就是15。虽然JVM提供了参数来设置分代年龄的大小，但是这个大小不能超过15。从设计角度来看，当一个对象触发了最大值15次gc，还没有办法被回收，就只能移动到old generation了。另外，设计者还引入了动态对象年龄判断的方式来决定把对象转移到old generation，也就是说不管这个对象的gc年龄是否达到了15次，只要满足动态年龄判断的依据，也同样会转移到old generation。

第二种情况就是，创建了一个很大的对象，这个对象的大小超过了jvm里面的一个参数max tenuring thread hold值，这个时候不会创建在eden区，新对象直接进入老年代。

第三种情况，如果在Survivor区里面，同一年龄的所有对象大小的总和大于Survivor区大小的一半，年龄大于等于这个年龄对象的，就可以直接进入老年代，举个例子，存活区只能容纳5个对象，有五个对象，1岁，2岁，2岁，2岁，3岁，3个2岁的对象占了存活区空间的5分之三，大于这个空间的一半了，这个时候大于等于2岁的对象，需要移动到老年代里面，也就是3个2岁的，一个3岁的对象移动到老年代里面。

空间分配担保

第四种情况就是eden区存活的对象，超过了存活区的大小，会直接进入老年代里面。另外在发生minor gc之前，必须检查老年代最大可用连续空间，是不是大于新生代所有对象的总空间，如果大于，这一次的minor gc可以确保是安全的，如果不成立，jvm会检查自己的handlepromotionfailure这个值是true还是false。true表示运行担保失败，false则表示不允许担保失败。如果允许，就会检查老年代最大可用连续空间是不是大于历次晋升到老年代平均对象大小，如果大于就尝试一次有风险的minorgc，如果小于或者不允许担保失败，那就直接进行fgc了。

举个例子，在minorgc发生之前，年轻代里面有1g的对象，这个时候，老年代瑟瑟发抖，jvm为了安慰这个老年代，它在minor gc之前，检查一下老年代最大可用连续空间，假设老年代最大可用连续空间是2g，jvm就会拍拍老年代的肩膀说，放心，哪怕年轻代里面这1g的对象全部给你，你也吃的下，你的空间非常充足，这个时候，老年代就放心了。

但是大部分情况下，在minor gc发生之前，jvm检查完老年代最大可用连续空间以后，发现只有500M，这个时候虚拟机不会直接告诉老年代你的空间不够，这个时候会进行第二次检查，检查自己的一个参数handlepromotionfailure的值是不是允许担保失败，如果允许担保失败，就进行第三次检查。

检查老年代最大可用连续空间是不是大于历次晋升到老年代平均对象大小，假设历次晋升到老年代平均对象大小是300M，现在老年代最大可用连续空间只有500M，很明显是大于的，那么它会进行一次有风险的minorgc，如果gc之后还是大于500M，那么就会引发fgc了，但是根据以往的一些经验，问题不大，这个就是允许担保失败。

假设历次晋升到老年代平均对象大小是700M，现在老年代最大可用连续空间只有500M，很明显是小于的，minorgc风险太大，这个时候就直接进行fgc了，这就是我们所说的空间分配担保。

Serial Old

Serial Old就是老年代下使用标记整理算法，单线程运行的垃圾回收器。

Parallel old

Parallel old也是老年代下使用标记整理算法，可以进行吞吐量控制的多线程回收器，在JDK1.6才开始提供，在JDK1.6之前，新生代使用ParallelScavenge 收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器而出现的。

上面的Serial Old，Parallel Old这二个垃圾回收器使用的是标记整理算法.

标记整理算法

标记整理算法是标记后将存活对象移向内存的一端，然后清除端边界外的对象。标记整理算法可以弥补标记清除算法当中，内存碎片的缺点，也消除了复制算法当中，内存使用率只有90%的现象，不过也有缺点，就是效率也不高，它不仅要标记所有存活对象，还要整理所有存活对象的引用地址。从效率上来说，标记整理算法要低于复制算法。

CMS

CMS是老年代使用标记清除算法，并发收集低停顿的多线程垃圾回收器。这个垃圾回收器可以重点讲一下，CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下4个阶段：

初始标记，只是标记一下GC Roots，能直接关联的对象，速度很快，需要暂停所有的工作线程。

并发标记，进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。

重新标记，为了修正在并发标记期间，因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，需要暂停所有的工作线程。

并发清除，清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。

但是很明显无法处理浮动垃圾，就是已经标记过的对象，开始进行并发清除的时候，这个时候又有垃圾对象产生，这个时候，没办法清除这部分的浮动垃圾了，还有一个问题就是容易产生大量内存碎片，这和它的算法特性相关。

标记清除算法

标记清除算法分为两个阶段，标注和清除。标记阶段标记出所有需要回收的对象，清除阶段回收被标记的对象所占用的空间。

CMS使用标记清除算法看中的就是它的效率高，只不过内存碎片化严重，后续可能发生大对象不能找到可利用空间的问题。

G1

G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，每个区域又可以根据分代理论分为eden区，Survivor区，只要这个区域里面出现了一个对象，超过了这个区域空间的一半就可以把它当作大对象，g1专门开辟了一块空间用来存储大对象，这个区域的大小，可以通过jvm的参数去设置，取值范围是1~32mb之间，那么如果有一个对象超过了32mb，那么jvm会分配二个连续的区域，用来存储这个大对象。

跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，保证了G1 收集器可以在有限时间获得最高的垃圾收集效率。而且基于标记整理算法，不产生内存碎片。可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。在jdk1.9的时候，被设置成默认的垃圾回收器了。

安全点

目前Java虚拟机都是采用准确是GC，当执行系统停下来之后，并不需要一个不漏的检查完所有执行上下文和全局的引用位置，虚拟机有办法直接得到哪些地方存放在对象的引用。在HotSpot中，使用了一组OopMap数据结构来实现这个功能。

当一个类加载完之后，HotSpot就把对象是什么类型数据计算出来，在JIT（即时编译）的时候也记录下栈和寄存器哪些位置是引用，这样GC时就可以直接得到有哪些对象的引用。

OopMap不可能为每一条指令都创建一个OopMap只能在特定的位置记录一下，这些位置称为安全点。也就是说程序并非在任何地方都可以进行GC，只有到达安全点之后才可以GC。

安全点的选择不能太少，不能让GC等待的时间太长，也不能太多而影响正常的程序运行速度。所以安全点的选定基本是以程序“是否具有让程序长时间运行的特征”为标准，例如方法调用、循环跳转、异常跳转等地方，具有这些基本功能的指令才产生安全点。

更具体点在HotSpot中，安全点的位置：

• 方法返回之前
• 调用某个方法之后
• 抛出异常的位置
• 循环的末尾

另外在垃圾收集发生时，多线程的程序要所有的线程都跑到安全点都停下来

如何在垃圾收集发生时让所有线程都跑到最近的安全点？

有两种方案可供选择：抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension）

抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有 用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎 没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。

主动式中断的思想是当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个 线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。 轮询标志的地方和安全点是重合的，另外还要加上所有创建对象和其他需要在Java堆上分配内存的地方，这是为 了检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。

程序“不执行”的时候线程如何达到安全点？

安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入垃圾收集过程的安全点。但是，程序“不执行” 的时候呢？所谓的程序不执行就是没有分配处理器时间，典型的场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续 等待线程重新被激活分配处理器时间。

对于这种情况，就必须引入安全区域来解决。 安全区域是指能够确保在某一段代码片段之中，引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾收集都是安全的。我们也可以把安全区域看作被扩展拉伸了的安全点。

当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。

当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段），如果完成了，那线程就当作没事发生过，继续执行；否则它就必须一直等待，直到收到可以离开安全区域的信号为止。

JIT技术

提出疑问：为什么应用刚启动的时候比较卡，过一会就好了？

解答：

JVM 中内置了解释器，在运行时对字节码进行解释翻译成机器码，然后再执行。

解释器的执行方式是一边翻译，一边执行，因此执行效率很低。为了解决这样的低效问题，HotSpot 引入了JIT 技术。

有了 JIT 技术之后，JVM 虽然还是通过解释器进行解释执行，但是，当 JVM 发现某个方法或代码块运行时执行的特别频繁的时候，就会认为这是“热点代码”，然后 JIT 会把部分“热点代码”翻译成本地机器相关的机器码，并进行优化，然后再把翻译后的机器码缓存起来，以备下次使用，这也是 HotSpot 虚拟机的名字的由来。

JIT 优化是在运行期进行的，并且也不是 Java 进程刚一启动就能优化的，是需要先执行一段时间的，因为他需要先知道哪些是热点代码。

所以，在 JIT 优化开始之前，我们的所有请求，都是要经过解释执行的，这个过程就会相对慢一些。

如果请求量比较大的的话，这种问题就会更加明显，在应用启动过程中，会有大量的请求过来，这就会导致解释器持续的在努力工作。一旦解释器对 CPU 资源占用比较大的话，就会间接的导致 CPU、LOAD 等飙高，导致应用的性能进一步下降。

这也是为什么很多应用在发布过程中，会出现刚刚重启好的应用会发生大量的超时问题了。而随着请求的不断增多，JIT 优化就会被触发，这就是使得后续的热点请求的执行可能就不需要在通过解释执行了，直接运行 JIT 优化后缓存的机器码就行了。

解决思路：

1、提升 JIT 优化的效率

2、降低瞬时请求量

在提升 JIT 优化效率的设计上，大家可以了解一下阿里研发的 JDK——Dragonwell。

这个相比 OpenJDK 提供了一些专有特性，其中一项叫做JwarmUp的技术就是解决 JIT 优化效率的问题的。

这个技术主要是通过记录 Java 应用上一次运行时候的编译信息到文件中，在下次应用启动时，读取该文件，从而在流量进来之前，提前完成类的加载、初始化和方法编译，从而跳过解释阶段，直接执行编译好的机器码。

除了针对 JDK 做优化之外，还可以采用另外一种方式来解决这个问题，那就是做预热。

很多人都听说过缓存预热，其实思想是类似的。

就是说在应用刚刚启动的时候，通过调节负载均衡，不要很快的把大流量分发给他，而是先分给他一小部分流量，通过这部分流量来触发 JIT 优化，等优化好了之后，再把流量调大。

可达性分析

在可达性分析法中，可以作为GCRoots节点的，一般内容都会很大（方法区有时候就有数百M），要想检查完所有符合要求的对象，必定很费时间。另外可达性分析应当是对某瞬间的程序快照进行的，不然一边进行可达性分析，一边程序运行，最后出的结果肯定是牛头不对马尾。这个时间点导致GC进行时必须停顿所有Java执行的线程。

通过gc root根节点，从跟节点开始进行引用链的搜索，如果对象搜索不到，就证明这个对象是不可达的，就会在三色标记算法把这个对象标记为白色不可达，最终引发垃圾回收。

gc root是可达性分析的起点，gc root有几种，第一种，虚拟机栈里面引用的对象，也就是栈帧中的本地变量，第二种，本地方法栈里面的引用对象，第三种，方法区里面的静态属性引用的对象，第四种，方法区里面的常量引用对象，第五种，java虚拟机内部也有引用，这个也需要作为gc root，第六种，锁，锁的获取和释放，获取的话会持有对象，这些都是作为gc root的引用点。

四种引用类型

强引用

强引用就是最常见的Object a = new Object();这种就是最强的一个引用，只要这个关系还在，就不会被垃圾回收掉。

软引用

软引用就是描述这个对象还有用，但是它不是一个必须回收的对象，只有系统即将要发送内存溢出的情况下，会把这些对象列入回收的范围里面，进行第二次垃圾回收，如果回收之后，还是没有足够的内存，才会抛出异常。

弱引用

弱引用，被弱引用引用的对象，只能生存到下一次垃圾回收器进行垃圾收集。

虚引用

虚引用，它是最弱的一种引用，可以称为幽灵引用，它的存在不会对结构造成任何的影响，没法通过虚引用找到这个对象的实例。

gc的过程中对象是否能回收

当对象不可达就意味着这个对象要被回收，但是它不会立马就回收，对象不可达会把它放到一个F-Queue的队列里面，这个队列里面会启用一个低优先级的线程，去读取这些不可达的对象，然后一个一个的调用对象的finalize方法，如果对象的finalize方法被覆盖过，被调用过，这个时候虚拟机将这两种情况都视为“没有必要执行”。

这个时候这个不可达对象逃过了垃圾回收，稍后会由一条由虚拟机自动建立的、低调度优先级的 Finalizer线程去执行F-Queue中对象的finalize()方法。

finalize()方法是对象逃脱死亡命运的最后一次机会，收集器将对F-Queue中的对象进行第二次小规模的标记。

如果对象重新与引用链上的任何一个对象建立关联，那在第二次标记时它将被移出“即将回收”的集合。
如果对象这时候还没有逃脱，那基本上它就真的要被回收了。

三色标记

三色标记，这三色就是白黑灰，白色表示对象不可达，黑色表示已经被访问过了，它关联的对象也扫描了，灰色就是还有一部分对象没有被扫描过。

跨代引用

跨代引用，年轻代中有一个对象被老年代的对象引用了，这个时候进行minor gc。正常我们的思路是，年轻代里面的对象被老年代里面的对象引用的话，就进行一个遍历，遍历老年代里面的对象。但是老年代里面的对象是很多的，遍历这个是很消耗性能的，这个时候jvm引入了一个记忆集的抽象数据结构。它用于记录从非收集区域指向收集区域的一个指针集合的抽象数据结构。比如说，我们在年轻代里面进行minor gc，它里面有一个记忆集，记录了老年代引用年轻代的对象的指针。如果记忆集里面有当前对象的引用，那么这个对象就不能被回收。

逃逸分析

逃逸分析原理：

逃逸分析有三种程度，从不逃逸，方法逃逸，线程逃逸，这三个由低到高表示不同逃逸的程度。

方法逃逸：分析对象动态作用域，当一个对象在方法里面定义之后，可能会被外部方法引用，比如作为参数传到其他方法里面去，这个叫方法逃逸。
线程逃逸：一个对象可能被外部线程访问到，比如可以赋值给其他线程能访问的实例变量，这个叫线程逃逸。

优化手段有三种：第一种是栈上分配，标量替换，锁清除（同步清除）。

栈上分配，java堆中的对象，对于各个线程都是共享可见的，只要持有这个对象的引用，就可以访问到堆中存储的对象数据。虚拟机的垃圾收集子系统会回收堆中不再使用的对象，但是回收动作无论是标记筛选出可回收对象， 还是回收和整理内存，都需要耗费大量资源。如果确定一个对象不会逃逸出线程之外，那让这个对象在栈上分 配内存将会是一个很不错的主意，对象所占用的内存空间就可以随栈帧出栈而销毁。在一般应用中，完全不会 逃逸的局部对象和不会逃逸出线程的对象所占的比例是很大的，如果能使用栈上分配，那大量的对象就会随着 方法的结束而自动销毁了，垃圾收集子系统的压力将会下降很多。栈上分配可以支持方法逃逸，但不能支持线 程逃逸。

标量替换：一个数据已经无法再分解成更小的数据来表示了，Java虚拟机中的原始数据类型 （int、long等数值类型及reference类型等）都不能再进一步分解了，那么这些数据就可以被称为标量。

一个数据可以继续分解，那它就被称为聚合量，Java中的对象就是典型的聚合量。如果把一个Java对象拆散，根据程序访问的情况，将其用到的成员变量恢复为原始类型来访问，这个过程就称为标量替换。

假如逃逸分析能够证明一个对象不会被方法外部访问，并且这个对象可以被拆散，那么程序真正执行的时候将可能不去创建这个对象，而改为直接创建它的若干个被这个方法使用的成员变量来代替。

将对象拆分后，除了可以让对象的成员变量在栈上（栈上存储的数据，很大机会被虚拟机分配至物理机器的高速寄存器中存储）分配和读写之外，还可以为后续进一 步的优化手段创建条件。标量替换可以视作栈上分配的一种特例，实现更简单（不用考虑整个对象完整结构的分配）， 但对逃逸程度的要求更高，它不允许对象逃逸出方法范围内。

同步消除：线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不 会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争，对这个变量实施的同步措施也就可以 安全地消除掉。

public String concatString(String s1,String s2,String s3){

	StringBuffer sb = new StringBuffer();
	sb.append(s1);
	sb.append(s2);
	sb.append(s3);
	
	return sb.toString();
}

每个StringBuffer.append()方法中都有一个同步块，锁就是sb对象。 虚拟机观察变量sb，经过逃逸分析后会发现它的动态作用域被限 制在concatString()方法内部。也就是sb的所有引用都永远不会逃 逸到concatString()方法之外，其他线程无法访问到它，所以这里 虽然有锁，但是可以被安全地消除掉。在解释执行时这里仍然会 加锁，但在经过服务端编译器的即时编译之后，这段代码就会忽 略所有的同步措施而直接执行。

内存泄漏

内存泄漏：是指创建的对象已经没有用处，正常情况下应该会被垃圾收集器回收，但是由于该对象仍然 被其他对象进行了无效引用，导致不能够被垃圾收集器及时清理，这种现象称之为内存泄漏。

内存堆积

内存泄漏会导致内存堆积，最终发生内存溢出，导致OOM。 发生内存泄漏大部分是由于程序代码导致的，排查方法一般是使用 visualVM 进行heap dump，查看占用 空间比较多的 class 对象，然后检查该对象的instances 以及 reference引用，最终定位到程序代码。 如果堆内存比较大，进行head dump 产生的资源消耗不可接受，可以尝试使用轻量级的jmap生成堆转储快照 分析，思路与使用可视化工具一样。

JVM调优

JVM调优情况十分复杂，各种情况都可能导致垃圾回收不能够达到预想的效果。对于场景问题，可以从如下几个大方向进行设计：

1. 大访问压力下，MGC 频繁一些是正常的，只要MGC 延迟不导致停顿时间过长或者引发FGC ，那可以适当的增大Eden 空间大小，降低频繁程度，同时要保证，空间增大对垃圾回收产生的停顿时间增长是可以接受的。
2. 如果MinorGC 频繁，且容易引发 Full GC。需要从如下几个角度进行分析。
   a：每次MGC存活的对象的大小，是否能够全部移动到 S1区，如果S1 区大小 < MGC 存活的对象大小，这批对象会直接进入老年代。注意 了，这批对象的年龄才1岁，很有可能再多等1次MGC 就能被回收了，可是却进入了老年代，只能等到Full GC 进行回收，很可怕。这种情况下，应该在系统压测的情况下，实时监控MGC存活的对象大小，并合理调整eden和s 区的大小以及比例。
   b：还有一种情况会导致对象在未达到15岁之前，直接进入老年代，就是S1区的对象，相同年龄的对象所占总空间大小>s1区空间大小的一半，所以为了应对这种情况，对于S区的大小的调整就要考虑：尽量保证峰值状态下，S1区的对象所占空间能够在MGC的过程中，相同对象年龄所占空间不大于S1区空间的一半， 因此对于S1空间大小的调整，也是十分重要的。
3. 由于大对象创建频繁，导致Full GC 频繁。对于大对象，JVM专门有参数进行控制，-XX： PretenureSizeThreshold。超过这个参数值的对象，会直接进入老年代，只能等到full GC 进行回收，所以在系统压测过程中，要重点监测大对象的产生。如果能够优化对象大小，则进行代码层面的优化，优化如：根据业务需求看是否可以将该大对象设置为单例模式下的对象，或者该大对象是否可以进行拆分使用，或者如果大对象确定使用完成后，将该对象赋值为null，方便垃圾回收。
   如果代码层面无法优化，则需要考虑：
   a:调高-XX： PretenureSizeThreshold参数的大小，使对象有机会在eden区创建，有机会经历MGC以被回收。但是这个参数的调整要结合MGC过程中Eden区的大小是否能够承载，包括S1区的大小承载问题。
   b：这是最不希望发生的情况， 如果必须要进入老年代，也要尽量保证，该对象确实是长时间使用的对象，放入老年代的总对象创建量不会造成老年代的内存空间迅速长满发生Full GC，在这种情况下，可以通过定时脚本，在业务系统不繁忙情况下，主动触发full gc。
4. MGC 与 FGC 停顿时间长导致影响用户体验。其实对于停顿时间长的问题无非就两种情况：
   a：gc 真实回收过程时间长，即real time时间长。这种时间长大部分是因为内存过大导致，从标记到清理的过程中需要对很大的空间进行操作，导致停顿时间长。这种情况，要考虑减少堆内存大 小，包括新生代和老年代，比如之前使用16G的堆内存，可以考虑将16G 内存拆分为4个4G的内存区域，可以单台机器部署JVM逻辑集群，也可以为了降低GC回收时间，进行4节点的分布式部署，这里的分布式部署是为了降低 GC垃圾回收时间。
   b：gc真实回收时间 real time 并不长，但是user time(用户态执行时间) 和 sys time（核心态执行时间）时间长，导致从客户角度来看，停顿时间过长。这种情况，要考虑线程是否及时达到了安全点，通过-XX：+PrintSafepointStatistics和-XX： PrintSafepointStatisticsCount=1去查看安全点日志，如果有长时间未达到安全点的线程，再通过参数-XX： +SafepointTimeout和-XX：SafepointTimeoutDelay=2000两个参数来找到大于2000ms到达安全点的线程，这里 的2000ms可以根据情况自己设置，然后对代码进行针对的调整。除了安全点问题，也有可能是操作系统本身负载比较高，导致处理速度过慢，线程达到安全点时间长，因此需要同时检测操作系统自身的运行情况。
5. 内存泄漏导致的MGC和FGC频繁，最终引发oom。纯代码级别导致的MGC和FGC频繁。如果是这种情况，那就只能对代码进行大范围的调整，这种情况就非常多了，而且会很糟糕。如大循环体中的new 对象，未使用合理容器进行对象托管导致对象创建频繁，不合理的数据结构使用等等。 总之，JVM的调优无非就一个目的，在系统可接受的情况下达到一个合理的MGC和FGC的频率以及可接受的回收时间

CPU飙高系统反应慢怎么排查？

1.CPU是整个电脑的核心计算资源，对于一个应用进程来说，CPU的最小执行单元是线程。

2.导致CPU飙高的原因有几个方面

• CPU上下文切换过多，对于CPU来说，同一时刻下每个CPU核心只能运行一个线程，如果有多个线程要执行，CPU只能通过上下文切换的方式来执行不同的线程。上下文切换需要做两个事情

  1. 保存运行线程的执行状态
  2. 让处于等待中的线程执行

  这两个过程需要CPU执行内核相关指令实现状态保存，如果较多的上下文切换会占据大量CPU资源，从而使得cpu无法去执行用户进程中的指令，导致响应速度下降。在Java中，文件IO、网络IO、锁等待、线程阻塞等操作都会造成线程阻塞从而触发上下文切换

• CPU资源过度消耗，也就是在程序中创建了大量的线程，或者有线程一直占用CPU资源无法被释放，比如死循环！

CPU利用率过高之后，导致应用中的线程无法获得CPU的调度，从而影响程序的执行效率！

3.既然是这两个问题导致的CPU利用率较高，于是我们可以通过top命令，找到CPU利用率较高的进程，在通过Shift+H找到进程中CPU消耗过高的线程，这里有两种情况。

1. CPU利用率过高的线程一直是同一个，说明程序中存在线程长期占用CPU没有释放的情况，这种情况直接通过jstack获得线程的Dump日志，定位到线程日志后就可以找到问题的代码。
2. CPU利用率过高的线程id不断变化，说明线程创建过多，需要挑选几个线程id，通过jstack去线程dump日志中排查。

4.最后有可能定位的结果是程序正常，只是在CPU飙高的那一刻，用户访问量较大，导致系统资源不够。