private List<BookInfoVo> removeDupliByRecordId(List<BookInfoVo> books) {
	Set<BookInfoVo> bookSet = new TreeSet<>((o1, o2)->o1.getRecordId().compareTo(o2.getRecordId()));
          personSet.addAll(books);
        return new ArrayList<BookInfoVo>(bookSet);
    }

这也是大多数人第一想到的,借助 TreeSet 去重,其中 TreeSet 的其中一个构造函数接收一个排序的算法,同时这也会用到 TreeSet 的去重策略上.

/**
     * Constructs a new, empty tree set, sorted according to the specified
     * comparator.  All elements inserted into the set must be <i>mutually
     * comparable</i> by the specified comparator: {@code comparator.compare(e1,
     * e2)} must not throw a {@code ClassCastException} for any elements
     * {@code e1} and {@code e2} in the set.  If the user attempts to add
     * an element to the set that violates this constraint, the
     * {@code add} call will throw a {@code ClassCastException}.
     *
     * @param comparator the comparator that will be used to order this set.
     *        If {@code null}, the {@linkplain Comparable natural
     *        ordering} of the elements will be used.
     */
public TreeSet(Comparator<? super E> comparator) {
        this(new TreeMap<>(comparator));
    }

第二种: 炫酷的java8写法]

/*方法二:炫酷的java8写法*/
ArrayList<BookInfoVo> distinctLiost = list.stream()
                  .collect(
                          Collectors.collectingAndThen(
                                  Collectors.toCollection(() -> new TreeSet<>(Comparator.comparingLong(BookInfoVo::getRecordId))), ArrayList::new)
                  );

当然也可以根据多个属性去重

1
2

ArrayList<BookInfoVo> distinctLiost = list.stream().collect(Collectors.collectingAndThen(
  Collectors.toCollection(() -> new TreeSet<>(Comparator.comparing(o -> o.getName() + ";" + o.getAuthor()))), ArrayList::new)

如果没有第一种方法做铺垫,我们很可能一脸懵逼.

其实理解起来也不难:

关键在于Collectors.collectingAndThen( Collectors.toCollection(() -> new TreeSet<>(Comparator.comparingLong(BookInfoVo::getRecordId))), ArrayList::new)的理解,

collectingAndThen 这个方法的意思是: 将收集的结果转换为另一种类型: collectingAndThen,

因此上面的方法可以理解为,把 new TreeSet<>(Comparator.comparingLong(BookInfoVo::getRecordId))这个set转换为 ArrayList,这个结合第一种方法不难理解.

可以看到java8这种写法真是炫酷又强大!!!

java8类型互转

发表于 2022-02-28 更新于 2022-05-16 分类于语法 Waline：本文字数： 6.4k 阅读时长 ≈ 6 分钟

java8类型互转

List< Integer >、int[ ]、Integer[ ]相互转换

[toc]

下文中出现的list、ints、integers分别代表一个列表、一个int数组、一个Integer数组。
它们之间所谓的转化，其实是复制数据，互不干扰，可以理解为深拷贝。

int[ ] 转 List< Integer >

1	List<Integer> list = Arrays.stream(ints).boxed().collect(Collectors.toList());

Arrays.stream(ints) 之后返回的类型是 IntStream，IntStream 是一个接口继承自 BaseStream，BaseStream 又继承自AutoCloseable。所以我把IntStream看成一个方便对每个整数做操作的数据流。

之后调用了 boxed()，它的作用是对每个整数进行装箱，基本类型流转换为对象流，返回的是 Stream，Stream 也是继承自 BaseStream。所以这一步的作用是把 IntStream 转换成了 Stream。

最后通过collect方法将数据流 (Stream) 收集成了集合 ( List)，这里 collect 方法里传入的是一个收集器 (Collector)，它通过 Collectors.toList() 产生。

小结：

Arrays.stream(ints) 将基本类型数组转换为基本类型流。 int[ ] => IntStream
.boxed() 将基本类型流转换为对象流。 => Stream< Integer >
.collect(Collectors.toList()) 将对象流收集为集合。 => List< Integer >

int[ ] [ ] 转 List< List < Integer > >

1 2	String temp = Arrays.deepToString(fooArr).replaceAll("\\[","").replaceAll("\\]",""); List<String> fooList = new ArrayList<>(Arrays.asList(",")); //不对

1	List<List<Integer>> collect2 = Arrays.Stream(ints1).map(ar -> Arrays.stream(ar).boxed().collect(Collectors.toList())).collect(Collectors.toList());

int[ ] 转 Integer[ ]

1	Integer[] integers = Arrays.stream(ints).boxed().toArray(Integer[]::new);

一样的内容就不重复了，toArray(T[ ] :: new) 方法返回基本类型数组。
小结：

Arrays.stream(ints) 将基本类型数组转换为基本类型流。 int[ ] => IntStream
.boxed() 将基本类型流转换为对象流。=> Stream< Integer >
.toArray(Integer[ ]::new) 将对象流转换为对象数组。=> Integer[ ]

int[ ] [ ]转 Integer[ ] [ ]

1	Integer[][] integers3 = Arrays.stream(ints1).map(ints -> Arrays.stream(ints).boxed().toArray(Integer[]::new)).toArray(Integer[][]::new);

Integer[ ] 转 List< Integer >

1	List<Integer> list = Arrays.asList(integers);

这个就很简单了，通过Arrays类里的asList方法将数组装换为List。值得注意：

asList 返回的是 Arrays 里的静态私有类 ArrayList，而不是 java.util 里的 ArrayList，它无法自动扩容。

可以用下面2种方法生成可扩容的ArrayList：

1	List<Integer> list = new ArrayList<>(Arrays.asList(integers));

或者

1 2	List<Integer> list = new ArrayList<>(); Collections.addAll(list, integers);

Integer[ ] [ ]转 List< List < Integer > >

1 2	Integer[][] a = {{1,2,3},{1,2,3}}; List<List<Integer>> lists = Arrays.stream(a).map(Arrays::asList).collect(Collectors.toList());

Integer[ ] 转 int[ ]

1	int[] ints = Arrays.stream(integers).mapToInt(Integer::valueOf).toArray();

map的意思是把每一个元素进行同样的操作。mapToInt的意思是把每一个元素转换为int。mapToInt(Integer::valueOf)方法返回的是IntStream。
小结：

Arrays.stream(integers) 将对象数组转换为对象流。 Integer[ ] => Stream< Integer >
.mapToInt(Integer::valueOf) 将对象流转换成基本类型流。=> IntStream
.toArray() 将基本类型流转换为基本类型数组。 => int[ ]

Integer[ ] [ ]转 int[ ] [ ]

1 2	Integer[][] a = {{1,2,3},{1,2,3}}; int[][] ints1 = Arrays.stream(a).map(a1 -> Arrays.stream(a1).mapToInt(Integer::valueOf).toArray()).toArray(int[][]::new);

List< Integer > 转 int[ ]

1	int[] ints = list.stream().mapToInt(Integer::valueOf).toArray();

经过上面的说明，相信这里已经很好理解了，直接小结。
小结：

list.stream() 将列表转换为对象流。List< Integer > => Stream< Integer >
.mapToInt(Integer::valueOf) 将对象流转换为基本数据类型流。=> IntStream
.toArray() 将基本数据类型流转换为基本类型数组。=>int[ ]

List< List < Integer > > 转 int[ ] [ ]

List<List<Integer>> lists = ...;
int[][] arrays = lists.stream()                                // Stream<List<Integer>>
        .map(list -> list.stream().mapToInt(i -> i).toArray()) // Stream<int[]>
        .toArray(int[][]::new);

List< Integer > 转 Integer[ ]

1	Integer[] integers = list.toArray(new Integer[list.size()]);

1	Integer[] integers = list.stream().toArray(Integer[]::new); //不推荐

这个也很简单，方法里的参数是一个数组，所以要规定长度。也有无参的方法，但是要进行转型，所以不推荐使用。

List< List < Integer > > 转 Integer[ ] [ ]

List<List<Integer>> lists = ...;
Integer[][] arrays = lists.stream()                                // Stream<List<Integer>>
        .map(list -> list.toArray(new Integer[list.size()])) // Stream<Integer[]>
        .toArray(Integer[][]::new);

1
2
3

Integer[][] arrays = lists.stream()                                // Stream<List<Integer>>
        .map(l -> l.stream().toArray(String[]::new)) // Stream<Integer[]>
        .toArray(Integer[][]::new);

1	Integer[][] arrays = lists.stream().map(List::toArray).toArray(Integer[][]::new);

List< Character >、char[ ]、Character[ ]相互转换

char[ ] 转 List< Character >

1 2	char[] chars = {'a', 'b', 'c'}; List<Character> collect = new String(chars).chars().mapToObj(i -> (char) i).collect(Collectors.toList());

char[ ] [ ] 转 List< List < Character > >

1	List<List<Character>> collect2 = Arrays.stream(ints1).map(chars1 -> new String(chars1).chars().mapToObj(i -> (char) i).collect(Collectors.toList())).collect(Collectors.toList());

char[ ] 转 Character[ ]

1 2	char[] chars = {'a', 'b', 'c'}; Character[] characters1 = new String(chars).chars().mapToObj(i -> (char) i).toArray(Character[]::new);

char[ ] [ ]转 Character[ ] [ ]

1	Character[][] integers3 = Arrays.stream(ints1).map(chars -> new String(chars).chars().mapToObj(i->(char)i).toArray(Character[]::new)).toArray(Character[][]::new);

Character[ ] 转 List< Character >

1	List<Character> collect2 = Arrays.stream(characters).collect(Collectors.toList());

Character[ ] [ ]转 List< List < Character > >

1	List<List<Character>> lists = Arrays.stream(a).map(Arrays::asList).collect(Collectors.toList());

Character[ ] 转 char[ ]

1 2	char[] chars4 = Arrays.stream(characters1).map(String::valueOf).collect(Collectors.joining()).toCharArray();

Character[ ] [ ]转 char[ ] [ ]

1	char[][] ints1 = Arrays.stream(a).map(a1 -> Arrays.stream(a1).map(String::valueOf).collect(Collectors.joining()).toCharArray()).toArray(char[][]::new);

List< Character > 转 char[ ]

1	char[] value = characters.stream().map(String::valueOf).collect(Collectors.joining()).toCharArray();

1 2	Character[] charArr = characters.toArray(new Character[characters.size()]); char[] value = ArrayUtils.toPrimitive(charArr);

List< List < Character > > 转 char[ ] [ ]

1
2
3

char[][] arrays = lists.stream()                                // Stream<List<Integer>>
                .map(list -> list.stream().map(String::valueOf).collect(Collectors.joining()).toCharArray()) // Stream<int[]>
                .toArray(char[][]::new);

List< Character > 转 Character[ ]

1	Character[] characters2 = Arrays.stream(characters1).toArray(Character[]::new);

List< List < Character > > 转 Character[ ] [ ]

1 2	Character[][] integers1 = lists.stream() // Stream<List<Integer>> .map(list -> list.toArray(new Character[list.size()])).toArray(Character[][]::new);

1
2
3

Character[][] integers2 = lists.stream()                                // Stream<List<Integer>>
                .map(l -> l.stream().toArray(Character[]::new))
                .toArray(Character[][]::new);

1	Character[][] integers = lists.stream().map(List::toArray).toArray(Character[][]::new);

注释书写

发表于 2022-02-28 更新于 2022-03-13 分类于语法 Waline：本文字数： 2.4k 阅读时长 ≈ 2 分钟

注释书写规范

一般情况下，源程序有效注释量必须在30％以上。注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。可以用注释统计工具来统计。
一、类和接口的注释

1. 类外注释

该注释放在 package 关键字之后，class 或者 interface 关键字之前。

说明：方便JavaDoc收集。
示例：

package com.huawei.msg.relay.comm;
/**
 * 注释内容
 */
public class CommManager

类和接口的注释内容：类的注释主要是一句话功能简述、功能详细描述。
格式：
1
2
3
4
/**
* 〈一句话功能简述〉
* 〈功能详细描述〉
*/

描述部分说明该类或者接口的功能、作用、使用方法和注意事项。
示例：

/**
 * LogManager 类集中控制对日志读写的操作。
 * 全部为静态变量和静态方法，对外提供统一接口。分配对应日志类型的读写器，
 * 读取或写入符合条件的日志纪录。
*/

2. 类内注释

类属性、公有和保护方法必须写注释。geter、seter方法不用写注释

示例：

/**
 * 注释内容
 */
private String logType;
/**
 * 注释内容
 */
public void write()

1).成员变量注释内容：成员变量的意义、目的、功能，可能被用到的地方。
2).公有和保护方法注释内容：列出方法的一句话功能简述、功能详细描述、输入参数、输出参数、返回值、违例等。
格式：

/**
 * 〈一句话功能简述〉
 * 〈功能详细描述〉
 * @param  [参数1] [in或out]  [参数1说明]
 * @param  [参数2] [in或out]  [参数2说明]
 * @return [返回类型说明]
 * @exception/throws [违例类型] [违例说明]
*/

说明： @exception或throws 列出可能仍出的异常。
示例：

/**
 * 用MD5算法计算输入字符串的32位摘要
 * @param sIn [in] 待处理的字符串
 * @param sOut [out] sIn的32为摘要，调用函数负责new sOut对象
 * @return boolean
 */
public static boolean getMd5(String sIn, StringBuffer sOut)

说明：
1）.注释应与其描述的代码相近，对代码的注释应放在其上方或右方（对单条语句的注释）相邻位置，不可放在下面，如放于上方则需与其上面的代码用空行隔开。
2）.注释与所描述内容进行同样的缩排。
3）.将注释与其上面的代码用空行隔开。
示例：

//注释
program code one
(空一格)   
//注释
program code two

二、方法与复杂逻辑的注释

对变量的定义和分支语句（条件分支、循环语句等）对复杂的分支必须编写注释，如果时间允许，建议对所有分支语句写注释。

说明：这些语句往往是程序实现某一特定功能的关键，对于维护人员来说，良好的注释帮助更好的理解程序，有时甚至优于看设计文档。

switch语句

switch语句下的case语句，如果因为特殊情况需要处理完一个case后进入下一个case处理，必须在该case语句处理完、下一个case语句前加上明确的注释。
说明：这样比较清楚程序编写者的意图，有效防止无故遗漏break语句。

边写代码边注释

修改代码同时修改相应的注释，以保证注释与代码的一致性。不再有用的注释要删除。

避免在注释中使用缩写

在使用缩写时或之前，应对缩写进行必要的说明，特别是不常用缩写。

用中文注释，禁止用英文写注释。
建议
避免在一行代码或表达式的中间插入注释。

说明：除非必要，不应在代码或表达中间插入注释，否则容易使代码可理解性变差。

通过对函数或过程、变量、结构等正确的命名以及合理地组织代码的结构，使代码成为自注释的。

说明：清晰准确的函数、变量等的命名，可增加代码可读性，并减少不必要的注释。

在代码的功能、意图层次上进行注释，提供有用、额外的信息。

说明：注释的目的是解释代码的目的、功能和采用的方法，提供代码以外的信息，帮助读者理解代码，防止没必要的重复注释信息。

示例：如下注释意义不大。

1 2	// 如果 receiveFlag 为真 if (receiveFlag)

而如下的注释则给出了额外有用的信息。
1
2
// 如果从连结收到消息
if (receiveFlag)

在程序块的结束行右方加注释标记，以表明某程序块的结束。

说明：当代码段较长，特别是多重嵌套时，这样做可以使代码更清晰，更便于阅读。

示例：参见如下例子。

if (...)
{
    program code1
    while (index < MAX_INDEX)
    {
        program code2
    } // end of while (index < MAX_INDEX) // 指明该条while语句结束
} // end of  if (...) // 指明是哪条if语句结束

方法内的单行注释使用 //。

说明：调试程序的时候可以方便的使用 /* 。。。*/ 注释掉一长段程序。

注释使用中文注释和中文标点，不得用英文写注释。方法和类描述的第一句话尽量使用简洁明了的话概括一下功能，然后加以句号。接下来的部分可以详细描述。

说明：JavaDoc工具收集简介的时候使用选取第一句话。

顺序实现流程的说明使用1、2、3、4在每个实现步骤部分的代码前面进行注释。

示例：如下是对设置属性的流程注释

//1、 判断输入参数是否有效。
...
// 2、设置本地变量。
...

一些复杂的算法代码需要说明。

示例：这里主要是对闰年算法的说明。
java //1. 如果能被4整除，是闰年； //2. 如果能被100整除，不是闰年.； //3. 如果能被400整除，是闰年.。 星期五, 23. 八月 2019 07:42下午

Java内存模型2

发表于 2022-02-28 更新于 2022-03-13 分类于技术 Waline：本文字数： 20k 阅读时长 ≈ 18 分钟

Java内存模型2

Spring、Netty、Mybatis 等框架的代码中大量运用了 Java 多线程编程技巧。并发编程处理的恰当与否，将直接影响架构的性能。本章通过对这些框架源码的分析，结合并发编程的常用技巧，来讲解多线程编程在这些主流框架中的应用。

Java 内存模型

JVM 规范定义了 Java 内存模型来屏蔽掉各种操作系统、虚拟机实现厂商和硬件的内存访问差异，以确保 Java 程序在所有操作系统和平台上能够达到一致的内存访问效果。

工作内存和主内存

Java 内存模型规定所有的变量都存储在主内存中，每个线程都有自己独立的工作内存，工作内存保存了对应该线程使用的变量的主内存副本拷贝。线程对这些变量的操作都在自己的工作内存中进行，不能直接操作主内存和其他工作内存中存储的变量或者变量副本。线程间的变量传递需通过主内存来完成，三者的关系如下图所示。

Java 内存操作协议

Java 内存模型定义了 8 种操作来完成主内存和工作内存的变量访问，具体如下。

read：把一个变量的值从主内存传输到线程的工作内存中，以便随后的 load 动作使用。
load：把从主内存中读取的变量值载入工作内存的变量副本中。
use：把工作内存中一个变量的值传递给 Java 虚拟机执行引擎。
assign：把从执行引擎接收到的变量的值赋值给工作内存中的变量。
store：把工作内存中一个变量的值传送到主内存中，以便随后的 write 操作。
write：工作内存传递过来的变量值放入主内存中。
lock：把主内存的一个变量标识为某个线程独占的状态。
unlock：把主内存中一个处于锁定状态的变量释放出来，被释放后的变量才可以被其他线程锁定。

内存模型三大特性

1、原子性

这个概念与事务中的原子性大概一致，表明此操作是不可分割，不可中断的，要么全部执行，要么全部不执行。 Java 内存模型直接保证的原子性操作包括 read、load、use、assign、store、write、lock、unlock 这八个。

2、可见性

可见性是指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是 volatile 变量都是如此，普通变量与 volatile 变量的区别是，volatile 的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此，可以说 volatile 保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。除了 volatile 外，synchronized 也提供了可见性，synchronized 的可见性是由 “对一个变量执行 unlock 操作之前，必须先把此变量同步回主内存中（执行 store、write 操作）” 这条规则获得。

3、有序性

单线程环境下，程序会 “有序的”执行，即：线程内表现为串行语义。但是在多线程环境下，由于指令重排，并发执行的正确性会受到影响。在 Java 中使用 volatile 和 synchronized 关键字，可以保证多线程执行的有序性。volatile 通过加入内存屏障指令来禁止内存的重排序。synchronized 通过加锁，保证同一时刻只有一个线程来执行同步代码。

volatile 的应用

打开 NioEventLoop 的代码中，有一个控制 IO 操作和其他任务运行比例的，用 volatile 修饰的 int 类型字段 ioRatio，代码如下。

1	private volatile int ioRatio = 50;

这里为什么要用 volatile 修饰呢？我们首先对 volatile 关键字进行说明，然后再结合 Netty 的代码进行分析。

关键字 volatile 是 Java 提供的最轻量级的同步机制，Java 内存模型对 volatile 专门定义了一些特殊的访问规则。下面我们就看它的规则。当一个变量被 volatile 修饰后，它将具备以下两种特性。

线程可见性：当一个线程修改了被 volatile 修饰的变量后，无论是否加锁，其他线程都可以立即看到最新的修改（什么叫立即看到最新的修改？感觉这句话太口语化且模糊，搞不太懂！），而普通变量却做不到这点。
禁止指令重排序优化：普通的变量仅仅保证在该方法的执行过程中所有依赖赋值结果的地方都能获取正确的结果，而不能保证变量赋值操作的顺序与程序代码的执行顺序一致。举个简单的例子说明下指令重排序优化问题，代码如下。

public class ThreadStopExample {

	private static boolean stop;

	public static void main(String[] args) throws InterruptedException {
		Thread workThread = new Thread(new Runnable() {
			public void run() {
				int i= 0;
				while (!stop) {
					i++;
					try{
						TimeUnit.SECONDS.sleep(1);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
				}
			}
		});
		workThread.start();
		TimeUnit.SECONDS.sleep(3);
		stop = true;
	}
}

我们预期程序会在 3s 后停止，但是实际上它会一直执行下去，原因就是虚拟机对代码进行了指令重排序和优化，优化后的指令如下。

1
2
3

if (!stop)
While(true)
	......

workThread 线程在执行重排序后的代码时，是无法发现变量 stop 被其它线程修改的，因此无法停止运行。要解决这个问题，只要将 stop 前增加 volatile 修饰符即可。volatile 解决了如下两个问题。第一，主线程对 stop 的修改在 workThread 线程中可见，也就是说 workThread 线程立即看到了其他线程对于 stop 变量的修改。第二，禁止指令重排序，防止因为重排序导致的并发访问逻辑混乱。

一些人认为使用 volatile 可以代替传统锁，提升并发性能，这个认识是错误的。volatile 仅仅解决了可见性的问题，但是它并不能保证互斥性，也就是说多个线程并发修改某个变量时，依旧会产生多线程问题。因此，不能靠 volatile 来完全替代传统的锁。根据经验总结，volatile 最适用的场景是 “ 一个线程写，其他线程读 ”，如果有多个线程并发写操作，仍然需要使用锁或者线程安全的容器或者原子变量来代替。下面我们继续对 Netty 的源码做分析。上面讲到了 ioRatio 被定义成 volatile，下面看看代码为什么要这样定义。

1 2	final long ioTime = System.nanoTime() - ioStartTime; runAllTasks(ioTime * (100 - ioRatio) / ioRatio);

通过代码分析我们发现，在 NioEventLoop 线程中，ioRatio 并没有被修改，它是只读操作。既然没有修改，为什么要定义成 volatile 呢？继续看代码，我们发现 NioEventLoop 提供了重新设置 IO 执行时间比例的公共方法。

public void setIoRatio(int ioRatio) {
    if (ioRatio <= 0 || ioRatio > 100) {
        throw new IllegalArgumentException("ioRatio: " + ioRatio + " (expected: 0 < ioRatio <= 100)");
    }
    this.ioRatio = ioRatio;
}

首先，NioEventLoop 线程没有调用该 set 方法，说明调整 IO 执行时间比例是外部发起的操作，通常是由业务的线程调用该方法，重新设置该参数。这样就形成了一个线程写、一个线程读。根据前面针对 volatile 的应用总结，此时可以使用 volatile 来代替传统的 synchronized 关键字，以提升并发访问的性能。

ThreadLocal 的应用及源码解析

ThreadLocal 又称为线程本地存储区（Thread Local Storage，简称为 TLS），每个线程都有自己的私有的本地存储区域，不同线程之间彼此不能访问对方的 TLS 区域。使用 ThreadLocal 变量的 set(T value)方法可以将数据存入该线程本地存储区，使用 get() 方法可以获取到之前存入的值。

ThreadLocal 的常见应用

不使用 ThreadLocal。

public class SessionBean {
    public static class Session {
        private String id;
        public String getId() {
            return id;
        }
        public void setId(String id) {
            this.id = id;
        }
    }

    public Session createSession() {
        return new Session();
    }

    public void setId(Session session, String id) {
        session.setId(id);
    }
    public String getId(Session session) {
        return session.getId();
    }
    public static void main(String[] args) {
    //没有使用ThreadLocal，在方法间共享session需要进行session在方法间的传递
        new Thread(() -> {
            SessionBean bean = new SessionBean();
            Session session = bean.createSession();
            bean.setId(session, "susan");
            System.out.println(bean.getId(session));
        }).start();
    }
}

上述代码中，session 需要在方法间传递才可以修改和读取，保证线程中各方法操作的是一个。下面看一下使用 ThreadLocal 的代码。

public class SessionBean {
//定义一个静态ThreadLocal变量session，就能够保证各个线程有自己的一份，并且方法可以方便获取，不用传递
    private static ThreadLocal<Session> session = new ThreadLocal<>();
    public static class Session {
        private String id;
        public String getId() {
            return id;
        }
        public void setId(String id) {
            this.id = id;
        }
    }

    public void createSession() {
        session.set(new Session());
    }

    public void setId(String id) {
        session.get().setId(id);
    }

    public String getId() {
        return session.get().getId();
    }

    public static void main(String[] args) {
        new Thread(() -> {
            SessionBean bean = new SessionBean();
            bean.createSession();
            bean.setId("susan");
            System.out.println(bean.getId());
        }).start();
    }
}

在方法的内部实现中，直接可以通过 session.get() 获取到当前线程的 session，省掉了参数在方法间传递的环节。

ThreadLocal 的实现原理

一般，类属性中的数据是多个线程共享的，但 ThreadLocal 类型的数据声明为类属性，却可以为每一个使用它（通过 set(T value)方法）的线程存储线程私有的数据，通过其源码我们可以发现其中的原理。

public class ThreadLocal<T> {

    /**
     * 下面的 getMap()方法 传入当前线程，获得一个ThreadLocalMap对象，说明每一个线程维护了
     * 自己的一个 map，保证读取出来的value是自己线程的。
     *
     * ThreadLocalMap 是ThreadLocal静态内部类，存储value的键值就是ThreadLocal本身。
     *
     * 因此可以断定，每个线程维护一个ThreadLocalMap的键值对映射Map。不同线程的Map的 key值 是一样的，
     * 都是ThreadLocal，但 value 是不同的。
     */
    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();
    }

    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }
}

ThreadLocal 在 Spring 中的使用

Spring 事务处理的设计与实现中大量使用了 ThreadLocal 类，比如，TransactionSynchronizationManager 维护了一系列的 ThreadLocal 变量，用于存储线程私有的事务属性及资源。源码如下。

/**
 * 管理每个线程的资源和事务同步的中心帮助程序。供资源管理代码使用，但不供典型应用程序代码使用。
 *
 * 资源管理代码应该检查线程绑定的资源，如，JDBC连接 或 Hibernate Sessions。
 * 此类代码通常不应该将资源绑定到线程，因为这是事务管理器的职责。另一个选项是，
 * 如果事务同步处于活动状态，则在首次使用时延迟绑定，以执行跨任意数量资源的事务。
 */
public abstract class TransactionSynchronizationManager {

	/**
	 *  一般是一个线程持有一个 独立的事务，以相互隔离地处理各自的事务。
	 *  所以这里使用了很多 ThreadLocal对象，为每个线程绑定 对应的事务属性及资源，
	 *  以便后续使用时能直接获取。
	 */
	private static final ThreadLocal<Map<Object, Object>> resources =
			new NamedThreadLocal<Map<Object, Object>>("Transactional resources");

	private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =
			new NamedThreadLocal<Set<TransactionSynchronization>>("Transaction synchronizations");

	private static final ThreadLocal<String> currentTransactionName =
			new NamedThreadLocal<String>("Current transaction name");

	private static final ThreadLocal<Boolean> currentTransactionReadOnly =
			new NamedThreadLocal<Boolean>("Current transaction read-only status");

	private static final ThreadLocal<Integer> currentTransactionIsolationLevel =
			new NamedThreadLocal<Integer>("Current transaction isolation level");

	private static final ThreadLocal<Boolean> actualTransactionActive =
			new NamedThreadLocal<Boolean>("Actual transaction active");

	/**
	 * 为当前线程 绑定 对应的resource资源
	 */
	public static void bindResource(Object key, Object value) throws IllegalStateException {
		Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key);
		Assert.notNull(value, "Value must not be null");
		Map<Object, Object> map = resources.get();
		// 如果当前线程的 resources中，绑定的数据map为空，则为 resources 绑定 map
		if (map == null) {
			map = new HashMap<Object, Object>();
			resources.set(map);
		}
		Object oldValue = map.put(actualKey, value);
		if (oldValue instanceof ResourceHolder && ((ResourceHolder) oldValue).isVoid()) {
			oldValue = null;
		}
		if (oldValue != null) {
			throw new IllegalStateException("Already value [" + oldValue + "] for key [" +
					actualKey + "] bound to thread [" + Thread.currentThread().getName() + "]");
		}
		if (logger.isTraceEnabled()) {
			logger.trace("Bound value [" + value + "] for key [" + actualKey + "] to thread [" +
					Thread.currentThread().getName() + "]");
		}
	}

	/**
	 * 返回当前线程绑定的所有资源
	 */
	public static Map<Object, Object> getResourceMap() {
		Map<Object, Object> map = resources.get();
		return (map != null ? Collections.unmodifiableMap(map) : Collections.emptyMap());
	}
}

ThreadLocal 在 Mybatis 中的使用

Mybatis 的 SqlSession 对象也是各线程私有的资源，所以对其的管理也使用到了 ThreadLocal 类。源码如下。

public class SqlSessionManager implements SqlSessionFactory, SqlSession {

  private final ThreadLocal<SqlSession> localSqlSession = new ThreadLocal<>();

  public void startManagedSession() {
    this.localSqlSession.set(openSession());
  }

  public void startManagedSession(boolean autoCommit) {
    this.localSqlSession.set(openSession(autoCommit));
  }

  public void startManagedSession(Connection connection) {
    this.localSqlSession.set(openSession(connection));
  }

  public void startManagedSession(TransactionIsolationLevel level) {
    this.localSqlSession.set(openSession(level));
  }

  public void startManagedSession(ExecutorType execType) {
    this.localSqlSession.set(openSession(execType));
  }

  public void startManagedSession(ExecutorType execType, boolean autoCommit) {
    this.localSqlSession.set(openSession(execType, autoCommit));
  }

  public void startManagedSession(ExecutorType execType, TransactionIsolationLevel level) {
    this.localSqlSession.set(openSession(execType, level));
  }

  public void startManagedSession(ExecutorType execType, Connection connection) {
    this.localSqlSession.set(openSession(execType, connection));
  }

  public boolean isManagedSessionStarted() {
    return this.localSqlSession.get() != null;
  }

  @Override
  public Connection getConnection() {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot get connection.  No managed session is started.");
    }
    return sqlSession.getConnection();
  }

  @Override
  public void clearCache() {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot clear the cache.  No managed session is started.");
    }
    sqlSession.clearCache();
  }

  @Override
  public void commit() {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot commit.  No managed session is started.");
    }
    sqlSession.commit();
  }

  @Override
  public void commit(boolean force) {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot commit.  No managed session is started.");
    }
    sqlSession.commit(force);
  }

  @Override
  public void rollback() {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot rollback.  No managed session is started.");
    }
    sqlSession.rollback();
  }

  @Override
  public void rollback(boolean force) {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot rollback.  No managed session is started.");
    }
    sqlSession.rollback(force);
  }

  @Override
  public List<BatchResult> flushStatements() {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot rollback.  No managed session is started.");
    }
    return sqlSession.flushStatements();
  }

  @Override
  public void close() {
    final SqlSession sqlSession = localSqlSession.get();
    if (sqlSession == null) {
      throw new SqlSessionException("Error:  Cannot close.  No managed session is started.");
    }
    try {
      sqlSession.close();
    } finally {
      localSqlSession.set(null);
    }
  }
}

J.U.C 包的实际应用

线程池 ThreadPoolExecutor

首先通过 ThreadPoolExecutor 的源码看一下线程池的主要参数及方法。

public class ThreadPoolExecutor extends AbstractExecutorService {

    /**
     * 核心线程数
     * 当向线程池提交一个任务时，若线程池已创建的线程数小于corePoolSize，即便此时存在空闲线程，
     * 也会通过创建一个新线程来执行该任务，直到已创建的线程数大于或等于corePoolSize
     */
    private volatile int corePoolSize;

    /**
     * 最大线程数
     * 当队列满了，且已创建的线程数小于maximumPoolSize，则线程池会创建新的线程来执行任务。
     * 另外，对于无界队列，可忽略该参数
     */
    private volatile int maximumPoolSize;
    /**
     * 线程存活保持时间
     * 当线程池中线程数 超出核心线程数，且线程的空闲时间也超过 keepAliveTime时，
     * 那么这个线程就会被销毁，直到线程池中的线程数小于等于核心线程数
     */
    private volatile long keepAliveTime;

    /**
     * 任务队列
     * 用于传输和保存等待执行任务的阻塞队列
     */
    private final BlockingQueue<Runnable> workQueue;

    /**
     * 线程工厂
     * 用于创建新线程。threadFactory 创建的线程也是采用 new Thread() 方式，threadFactory
     * 创建的线程名都具有统一的风格：pool-m-thread-n（m为线程池的编号，n为线程池中线程的编号
     */
    private volatile ThreadFactory threadFactory;

    /**
     * 线程饱和策略
     * 当线程池和队列都满了，再加入的线程会执行此策略
     */
    private volatile RejectedExecutionHandler handler;

    /**
     * 构造方法提供了多种重载，但实际上都使用了最后一个重载 完成了实例化
     */
    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue) {
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             Executors.defaultThreadFactory(), defaultHandler);
    }

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory) {
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             threadFactory, defaultHandler);
    }

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              RejectedExecutionHandler handler) {
        this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
             Executors.defaultThreadFactory(), handler);
    }

    public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
        if (corePoolSize < 0 ||
            maximumPoolSize <= 0 ||
            maximumPoolSize < corePoolSize ||
            keepAliveTime < 0)
            throw new IllegalArgumentException();
        if (workQueue == null || threadFactory == null || handler == null)
            throw new NullPointerException();
        this.corePoolSize = corePoolSize;
        this.maximumPoolSize = maximumPoolSize;
        this.workQueue = workQueue;
        this.keepAliveTime = unit.toNanos(keepAliveTime);
        this.threadFactory = threadFactory;
        this.handler = handler;
    }

    /**
     * 执行一个任务，但没有返回值
     */
    public void execute(Runnable command) {
        if (command == null)
            throw new NullPointerException();
        int c = ctl.get();
        if (workerCountOf(c) < corePoolSize) {
            if (addWorker(command, true))
                return;
            c = ctl.get();
        }
        if (isRunning(c) && workQueue.offer(command)) {
            int recheck = ctl.get();
            if (! isRunning(recheck) && remove(command))
                reject(command);
            else if (workerCountOf(recheck) == 0)
                addWorker(null, false);
        }
        else if (!addWorker(command, false))
            reject(command);
    }

    /**
     * 提交一个线程任务，有返回值。该方法继承自其父类 AbstractExecutorService，有多种重载，这是最常用的一个。
     * 通过future.get()获取返回值（阻塞直到任务执行完）
     */
    public <T> Future<T> submit(Callable<T> task) {
        if (task == null) throw new NullPointerException();
        RunnableFuture<T> ftask = newTaskFor(task);
        execute(ftask);
        return ftask;
    }

    /**
     * 关闭线程池，不再接收新的任务，但会把已有的任务执行完
     */
    public void shutdown() {
        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            checkShutdownAccess();
            advanceRunState(SHUTDOWN);
            interruptIdleWorkers();
            onShutdown(); // hook for ScheduledThreadPoolExecutor
        } finally {
            mainLock.unlock();
        }
        tryTerminate();
    }

    /**
     * 立即关闭线程池，已有的任务也会被抛弃
     */
    public List<Runnable> shutdownNow() {
        List<Runnable> tasks;
        final ReentrantLock mainLock = this.mainLock;
        mainLock.lock();
        try {
            checkShutdownAccess();
            advanceRunState(STOP);
            interruptWorkers();
            tasks = drainQueue();
        } finally {
            mainLock.unlock();
        }
        tryTerminate();
        return tasks;
    }

    public boolean isShutdown() {
        return ! isRunning(ctl.get());
    }
}

线程池执行流程，如下图所示。

Executors 提供的 4 种线程池

Executors 类通过 ThreadPoolExecutor 封装了 4 种常用的线程池：CachedThreadPool，FixedThreadPool，ScheduledThreadPool 和 SingleThreadExecutor。其功能如下。

CachedThreadPool：用来创建一个几乎可以无限扩大的线程池（最大线程数为 Integer.MAX_VALUE），适用于执行大量短生命周期的异步任务。
FixedThreadPool：创建一个固定大小的线程池，保证线程数可控，不会造成线程过多，导致系统负载更为严重。
SingleThreadExecutor：创建一个单线程的线程池，可以保证任务按调用顺序执行。
ScheduledThreadPool：适用于执行延时或者周期性任务。

如何配置线程池

CPU 密集型任务
尽量使用较小的线程池，一般为 CPU 核心数+1。因为 CPU 密集型任务使得 CPU 使用率很高，若开过多的线程数，会造成 CPU 过度切换。
IO 密集型任务
可以使用稍大的线程池，一般为 2*CPU 核心数。 IO 密集型任务 CPU 使用率并不高，因此可以让 CPU 在等待 IO 的时候有其他线程去处理别的任务，充分利用 CPU 时间。

线程池的实际应用

Tomcat 在分发 web 请求时使用了线程池来处理。

BlockingQueue

核心方法

public interface BlockingQueue<E> extends Queue<E> {

    // 将给定元素设置到队列中，如果设置成功返回true, 否则返回false。如果是往限定了长度的队列中设置值，推荐使用offer()方法。
    boolean add(E e);

    // 将给定的元素设置到队列中，如果设置成功返回true, 否则返回false. e的值不能为空，否则抛出空指针异常。
    boolean offer(E e);

    // 将元素设置到队列中，如果队列中没有多余的空间，该方法会一直阻塞，直到队列中有多余的空间。
    void put(E e) throws InterruptedException;

    // 将给定元素在给定的时间内设置到队列中，如果设置成功返回true, 否则返回false.
    boolean offer(E e, long timeout, TimeUnit unit)
        throws InterruptedException;

    // 从队列中获取值，如果队列中没有值，线程会一直阻塞，直到队列中有值，并且该方法取得了该值。
    E take() throws InterruptedException;

    // 在给定的时间里，从队列中获取值，时间到了直接调用普通的 poll()方法，为null则直接返回null。
    E poll(long timeout, TimeUnit unit)
        throws InterruptedException;

    // 获取队列中剩余的空间。
    int remainingCapacity();

    // 从队列中移除指定的值。
    boolean remove(Object o);

    // 判断队列中是否拥有该值。
    public boolean contains(Object o);

    // 将队列中值，全部移除，并发设置到给定的集合中。
    int drainTo(Collection<? super E> c);

    // 指定最多数量限制将队列中值，全部移除，并发设置到给定的集合中。
    int drainTo(Collection<? super E> c, int maxElements);
}

主要实现类

ArrayBlockingQueue
基于数组的阻塞队列实现，在 ArrayBlockingQueue 内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue 内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。
ArrayBlockingQueue 在生产者放入数据和消费者获取数据时，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于 LinkedBlockingQueue。ArrayBlockingQueue 和 LinkedBlockingQueue 间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的 Node 对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于 GC 的影响还是存在一定的区别。而在创建 ArrayBlockingQueue 时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。
LinkedBlockingQueue
基于链表的阻塞队列，同 ArrayListBlockingQueue 类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue 可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而 LinkedBlockingQueue 之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。
需要注意的是，如果构造一个 LinkedBlockingQueue 对象，而没有指定其容量大小，LinkedBlockingQueue 会默认一个类似无限大小的容量（Integer.MAX_VALUE），这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。
PriorityBlockingQueue
基于优先级的阻塞队列（优先级的判断通过构造函数传入的 Compator 对象来决定），但需要注意的是 PriorityBlockingQueue 并不会阻塞数据生产者，而只会在没有可消费的数据时，阻塞数据的消费者。因此使用的时候要特别注意，生产者生产数据的速度绝对不能快于消费者消费数据的速度，否则时间一长，会最终耗尽所有的可用堆内存空间。在实现 PriorityBlockingQueue 时，内部控制线程同步的锁采用的是公平锁。

CAS 指令和原子类（应用比较多的就是计数器）

互斥同步最主要的问题就是进行线程阻塞和唤醒所带来的性能的额外损耗，因此这种同步被称为阻塞同步，它属于一种悲观的并发策略，我们称之为悲观锁。随着硬件和操作系统指令集的发展和优化，产生了非阻塞同步，被称为乐观锁。简单地说，就是先进行操作，操作完成之后再判断操作是否成功，是否有并发问题，如果有则进行失败补偿，如果没有就算操作成功，这样就从根本上避免了同步锁的弊端。

目前，在 Java 中应用最广泛的非阻塞同步就是 CAS。从 JDK1.5 以后，可以使用 CAS 操作，该操作由 sun.misc.Unsafe 类里的 compareAndSwapInt() 和 compareAndSwapLong() 等方法实现。通常情况下 sun.misc.Unsafe 类对于开发者是不可见的，因此，JDK 提供了很多 CAS 包装类简化开发者的使用，如 AtomicInteger。使用 Java 自带的 Atomic 原子类，可以避免同步锁带来的并发访问性能降低的问题，减少犯错的机会。

java 名词

发表于 2022-02-28 更新于 2022-03-13 分类于技术 Waline：本文字数： 4.3k 阅读时长 ≈ 4 分钟

java 名词

“吃人”的那些Java名词：对象、引用、堆、栈️

经验都是慢慢积累的，天才不多｜第170篇

记得中学的课本上，有一篇名为《狂人日记》课文；那时候根本理解不了鲁迅写这篇文章要表达的中心思想，只觉得满篇的“吃人”令人心情压抑；老师在讲台上慷慨激昂的讲，大多数的同学同我一样，在课本面前“痴痴”的发呆。

作为一个有着8年Java编程经验的IT老兵，说起来很惭愧，我被Java当中的四五个名词一直困扰着：对象、引用、堆、栈、堆栈（栈可同堆栈，因此是四个名词，也是五个名词）。每次我看到这几个名词，都隐隐约约觉得自己在被一只无形的大口慢慢地吞噬，只剩下满地的衣服碎屑（为什么不是骨头，因为骨头也好吃）。

十几年后，再读《狂人日记》，恍然如梦：

鲁迅先生以狂人的口吻，再现了动乱时期下中国人的精神状态，视角新颖，文笔细腻又不乏辛辣之味。
当时的中国，混乱成了主色调。以清廷和孔教为主的封建旧思想还在潜移默化地影响着人们的思想，与此同时以革命和新思潮为主的现代思想已经开始了对大众灵魂的洗涤和冲击。

最近，和沉默王二技术交流群（120926808）的群友们交流后，Java中那四五个会吃人的名词：对象、引用、堆、栈、堆栈，似乎在脑海中也清晰了起来，尽管疑惑有时候仍然会在阴云密布时跑出来——正鉴于此，这篇文章恰好做一下归纳。

一、对象和引用

在Java中，尽管一切都可以看做是对象，但计算机操作的并非对象本身，而是对象的引用。 这话乍眼一看，似懂非懂。究竟什么是对象，什么又是引用呢？

先来看对象的定义：按照通俗的说法，每个对象都是某个类（class）的一个实例（instance）。那么，实例化的过程怎么描述呢？来看代码（类是String）：

1 2	new String("我是对象张三"); new String("我是对象李四");

在Java中，实例化指的就是通过关键字“new”来创建对象的过程。以上代码在运行时就会创建两个对象——“我是对象张三”和”我是对象李四”；现在，该怎么操作他们呢？

我们都去过公园，见过几个大爷，他们很有一番本领——个个都能把风筝飞得老高老高，徒留我们眼馋的份！风筝飞那么高，没办法直接用手拽着飞啊，全要靠一根长长的看不见的结实的绳子来牵引！操作Java对象也是这个理，得有一根绳——也就是接下来要介绍的“引用”（我们肉眼也常常看不见它）。

1
2
3

String zhangsan, lisi;
zhangsan = new String("我是对象张三");
lisi = new String("我是对象李四");

这三行代码该怎么理解呢？

先来看第一行代码：String zhangsan, lisi;——声明了两个变量zhangsan和lisi，他们的类型为String。

①、歧义：zhangsan和lisi此时被称为引用。

你也许听过这样一句古文：“神之于形，犹利之于刀；未闻刀没而利存，岂容形亡而神在？”这是无神论者范缜（zhen）的名言，大致的意思就是：灵魂对于肉体来说，就像刀刃对于刀身；从没听说过刀身都没了刀刃还存在，那么怎么可能允许肉体死亡了而灵魂还在呢？

“引用”之于对象，就好比刀刃之于刀身，对象还没有创建，又怎么存在对象的“引用”呢？

如果zhangsan和lisi此时不能被称为“引用”，那么他们是什么呢？答案很简单，就是变量啊！（鄙人理解）

②、误解：zhangsan和lisi此时的默认值为null。

应该说zhangsan和lisi此时的值为undefined——借用JavaScript的关键字；也就是未定义；或者应该是一个新的关键字uninitialized——未初始化。但不管是undefined还是uninitialized，都与null不同。

既然没有初始化，zhangsan和lisi此时就不能被使用。假如强行使用的话，编译器就会报错，提醒zhangsan和lisi还没有出生（初始化）；见下图。

如果把zhangsan和lisi初始化为null，编译器是认可的（见下图）；由此可见，zhangsan和lisi此时的默认值不为null。

再来看第二行代码：zhangsan = new String("我是对象张三");——创建“我是对象张三”的String类对象，并将其赋值给zhangsan这个变量。

此时，zhangsan就是”我是对象张三”的引用；“=”操作符赋予了zhangsan这样神圣的权利。

第三行代码lisi = new String("我是对象李四");和第二行代码zhangsan = new String("我是对象张三");同理。

现在，我可以下这样一个结论了——对象是通过new关键字创建的；引用是依赖于对象的；=操作符把对象赋值给了引用。

我们再来看这样一段代码：

String zhangsan, lisi;
zhangsan = new String("我是对象张三");
lisi = new String("我是对象李四");
zhangsan = lisi;

当zhangsan = lisi;执行过后，zhangsan就不再是”我是对象张三”的引用了；zhangsan和lisi指向了同一个对象（”我是对象李四”）；因此，你知道System.out.println(zhangsan == lisi);打印的是false还是true了吗？

二、堆、栈、堆栈

谁来告诉我，为什么有很多地方（书、博客等等）把栈叫做堆栈，把堆栈叫做栈？搞得我都头晕目眩了——绕着门柱估计转了80圈，不晕才怪！

我查了一下金山词霸，结果如下：

我的天呐，更晕了，有没有！怎么才能不晕呢？我这里有几招武功秘籍，你们尽管拿去一睹为快：

1）以后再看到堆、栈、堆栈三个在一起打牌的时候，直接把“堆栈”踢出去；这仨人不适合在一起玩，因为堆和栈才是老相好；你“堆栈”来这插一脚算怎么回事；这世界上只存在“堆、栈”或者“堆栈”（标点符号很重要哦）。

2）堆是在程序运行时在内存中申请的空间（可理解为动态的过程）；切记，不是在编译时；因此，Java中的对象就放在这里，这样做的好处就是：

当需要一个对象时，只需要通过new关键字写一行代码即可，当执行这行代码时，会自动在内存的“堆”区分配空间——这样就很灵活。

另外，需要记住，堆遵循“先进后出”的规则。就好像，一个和尚去挑了一担水，然后把一担水装缸里面，等到他口渴的时候他再用瓢舀出来喝。请放肆地打开你的脑洞脑补一下这个流程：缸底的水是先进去的，但后出来的。所以，我建议这位和尚在缸上贴个标签——保质期90天，过期饮用，后果自负！

还是记不住，看下图：

不好意思，这是鼎，不是缸，将就一下哈

3）栈，又名堆栈（简直了，完全不符合程序员的思维啊，我们陈许愿习惯说一就是一，说二就是二嘛），能够和处理器（CPU，也就是脑子）直接关联，因此访问速度更快；举个十分不恰当的例子哈——眼睛相对嘴巴是离脑子近的一方，因此，你可以一目十行，但绝对做不到一开口就读十行字，哪怕十个字也做不到。

既然访问速度快，要好好利用啊！Java就把对象的引用放在栈里。为什么呢？因为引用的使用频率高吗？

不是的，因为Java在编译程序时，必须明确的知道存储在栈里的东西的生命周期，否则就没法释放旧的内存来开辟新的内存空间存放引用——空间就那么大，前浪要把后浪拍死在沙滩上啊。

现在清楚堆、栈和堆栈了吧？

三、特殊的“对象”

先来看《Java编程思想》中的一段话：

在程序设计中经常用到一系列类型，他们需要特殊对待。之所以特殊对待，是因为new将对象存储于“堆”中，故用new创建一个对象──特别小、简单的变量，往往不是很有效。因此，不用new来创建这类变量，而是创建一个并非是引用的变量，这个变量直接存储值，并置于栈中，因此更加高效。

在Java中，这些基本类型有：boolean、char、byte、short、int、long、float、double和void；还有与之对应的包装器：Boolean、Character、Byte、Short、Integer、Long、Float、Double和Void；他们之间涉及到装箱和拆箱，我们有机会再聊。

看两行简单的代码：

1 2	int a = 3; int b = 3;

这两行代码在编译的时候是什么样子呢？

编译器当然是先处理int a = 3;，不然还能跳过吗？编译器在处理int a = 3;时在栈中创建了一个变量为a的内存空间，然后查找有没有字面值为3的地址，没找到，就开辟一个存放3这个字面值的地址，然后将a指向3的地址。

编译器忙完了int a = 3;，就来接着处理int b = 3;；在创建完b的变量后，由于栈中已经有3这个字面值，就将b直接指向3的地址；就不需要再开辟新的空间了。

依据上面的概述，我们假设在定义完a与b的值后，再令a=4，此时b是等于3呢，还是4呢？

思考一下，再看答案哈。

答案揭晓：当编译器遇到a = 4;时，它会重新搜索栈中是否有4的字面值，如果没有，重新开辟地址存放4的值；如果已经有了，则直接将a指向4这个地址；因此a值的改变不会影响到b的值哦。

最后，留个作业吧，下面这段代码在运行时会输出什么呢？

public class Test1 {
    public static void main(String args[]) {
        int a = 1;
        int b = 1;

        a = 2;

        System.out.println(a);
        System.out.println(b);

        TT t = new TT("T");
        TT t1 = t;
        t.setName("TT");


        System.out.println(t.getName());
        System.out.println(t1.getName());
    }
}

class TT{
    private String name;

    public TT (String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }

    public void setName(String name1) {
        this.name = name1;
    }
}

Java泛型类型擦除以及类型擦除带来的问题

发表于 2022-02-28 更新于 2022-03-13 分类于技术 Waline：本文字数： 11k 阅读时长 ≈ 10 分钟

Java泛型类型擦除以及类型擦除带来的问题

1.Java泛型的实现方法：类型擦除

大家都知道，Java的泛型是伪泛型，这是因为Java在编译期间，所有的泛型信息都会被擦掉，正确理解泛型概念的首要前提是理解类型擦除。Java的泛型基本上都是在编译器这个层次上实现的，在生成的字节码中是不包含泛型中的类型信息的，使用泛型的时候加上类型参数，在编译器编译的时候会去掉，这个过程成为类型擦除。

如在代码中定义 List<Object>和 List<String>等类型，在编译后都会变成 List，JVM看到的只是List，而由泛型附加的类型信息对JVM是看不到的。Java编译器会在编译时尽可能的发现可能出错的地方，但是仍然无法在运行时刻出现的类型转换异常的情况，类型擦除也是Java的泛型与C++模板机制实现方式之间的重要区别。

1-1.通过两个例子证明Java类型的类型擦除

例1.原始类型相等

public class Test {

    public static void main(String[] args) {

        ArrayList<String> list1 = new ArrayList<String>();
        list1.add("abc");

        ArrayList<Integer> list2 = new ArrayList<Integer>();
        list2.add(123);

        System.out.println(list1.getClass() == list2.getClass());
    }

}

在这个例子中，我们定义了两个 ArrayList数组，不过一个是 ArrayList<String>泛型类型的，只能存储字符串；一个是 ArrayList<Integer>泛型类型的，只能存储整数，最后，我们通过 list1对象和 list2对象的 getClass()方法获取他们的类的信息，最后发现结果为 true。说明泛型类型 String和 Integer都被擦除掉了，只剩下原始类型。

例2.通过反射添加其它类型元素

public class Test {

    public static void main(String[] args) throws Exception {

        ArrayList<Integer> list = new ArrayList<Integer>();

        list.add(1);  //这样调用add方法只能存储整形，因为泛型类型的实例为Integer

        list.getClass().getMethod("add", Object.class).invoke(list, "asd");

        for (int i = 0; i < list.size(); i++) {
            System.out.println(list.get(i));
        }
    }

}

在程序中定义了一个 ArrayList泛型类型实例化为 Integer对象，如果直接调用 add()方法，那么只能存储整数数据，不过当我们利用反射调用 add()方法的时候，却可以存储字符串，这说明了 Integer泛型实例在编译之后被擦除掉了，只保留了原始类型。

2.类型擦除后保留的原始类型

在上面，两次提到了原始类型，什么是原始类型？

原始类型 就是擦除去了泛型信息，最后在字节码中的类型变量的真正类型，无论何时定义一个泛型，相应的原始类型都会被自动提供，类型变量擦除，并使用其限定类型（无限定的变量用Object）替换。

例3.原始类型Object

class Pair<t> {
    private T value;
    public T getValue() {
        return value;
    }
    public void setValue(T  value) {
        this.value = value;
    }
}

Pair的原始类型为:

class Pair {
    private Object value;
    public Object getValue() {
        return value;
    }
    public void setValue(Object  value) {
        this.value = value;
    }
}

因为在 Pair<t></t>中，T 是一个无限定的类型变量，所以用 Object替换，其结果就是一个普通的类，如同泛型加入Java语言之前的已经实现的样子。在程序中可以包含不同类型的 Pair，如 Pair<String>或 Pair<Integer>，但是擦除类型后他们的就成为原始的 Pair类型了，原始类型都是 Object。

从上面的例2中，我们也可以明白 ArrayList<Integer>被擦除类型后，原始类型也变为 Object，所以通过反射我们就可以存储字符串了。

如果类型变量有限定，那么原始类型就用第一个边界的类型变量类替换。

比如: Pair这样声明的话

1	public class Pair<t extends comparable> {}

那么原始类型就是 Comparable。

要区分原始类型和泛型变量的类型。

在调用泛型方法时，可以指定泛型，也可以不指定泛型。

在不指定泛型的情况下，泛型变量的类型为该方法中的几种类型的同一父类的最小级，直到Object
在指定泛型的情况下，该方法的几种类型必须是该泛型的实例的类型或者其子类

public class Test {
    public static void main(String[] args) {

        /**不指定泛型的时候**/
        int i = Test.add(1, 2); //这两个参数都是Integer，所以T为Integer类型  
        Number f = Test.add(1, 1.2); //这两个参数一个是Integer，以风格是Float，所以取同一父类的最小级，为Number  
        Object o = Test.add(1, "asd"); //这两个参数一个是Integer，以风格是Float，所以取同一父类的最小级，为Object  

       /**指定泛型的时候*/
        int a = Test.<Integer>add(1, 2); //指定了Integer，所以只能为Integer类型或者其子类  
        int b = Test.<Integer>add(1, 2.2); //编译错误，指定了Integer，不能为Float  
        Number c = Test.<number>add(1, 2.2); //指定为Number，所以可以为Integer和Float  
    }

    //这是一个简单的泛型方法
    public static <t> T add(T x,T y){
        return y;
    }
}

其实在泛型类中，不指定泛型的时候，也差不多，只不过这个时候的泛型为 Object，就比如 ArrayList中，如果不指定泛型，那么这个 ArrayList可以存储任意的对象。

例4.Object泛型

public static void main(String[] args) {
    ArrayList list = new ArrayList();
    list.add(1);
    list.add("121");
    list.add(new Date());
}

3.类型擦除引起的问题及解决方法

因为种种原因，Java不能实现真正的泛型，只能使用类型擦除来实现伪泛型，这样虽然不会有类型膨胀问题，但是也引起来许多新问题，所以，SUN对这些问题做出了种种限制，避免我们发生各种错误。

3-1.先检查，再编译以及编译的对象和引用传递问题

Q: 既然说类型变量会在编译的时候擦除掉，那为什么我们往 ArrayList 创建的对象中添加整数会报错呢？不是说泛型变量String会在编译的时候变为Object类型吗？为什么不能存别的类型呢？既然类型擦除了，如何保证我们只能使用泛型变量限定的类型呢？

A: Java编译器是通过先检查代码中泛型的类型，然后再进行类型擦除，再进行编译。

例如：

public static  void main(String[] args) {

    ArrayList<String> list = new ArrayList<String>();
    list.add("123");
    list.add(123);//编译错误
}

在上面的程序中，使用 add方法添加一个整型，在IDE中，直接会报错，说明这就是在编译之前的检查，因为如果是在编译之后检查，类型擦除后，原始类型为 Object，是应该允许任意引用类型添加的。可实际上却不是这样的，这恰恰说明了关于泛型变量的使用，是会在编译之前检查的。

那么，这个类型检查是针对谁的呢？我们先看看参数化类型和原始类型的兼容。

以 ArrayList举例子，以前的写法:

1	ArrayList list = new ArrayList();

现在的写法:

1 2	ArrayList<String> list = new ArrayList<String>();

如果是与以前的代码兼容，各种引用传值之间，必然会出现如下的情况：

1 2	ArrayList<String> list1 = new ArrayList(); //第一种情况 ArrayList list2 = new ArrayList<String>(); //第二种情况

这样是没有错误的，不过会有个编译时警告。

不过在第一种情况，可以实现与完全使用泛型参数一样的效果，第二种则没有效果。

因为类型检查就是编译时完成的， new ArrayList()只是在内存中开辟了一个存储空间，可以存储任何类型对象，而真正设计类型检查的是它的引用，因为我们是使用它引用 list1来调用它的方法，比如说调用 add方法，所以 list1引用能完成泛型类型的检查。而引用 list2没有使用泛型，所以不行。

举例子：

public class Test {

    public static void main(String[] args) {

        ArrayList<String> list1 = new ArrayList();
        list1.add("1"); //编译通过
        list1.add(1); //编译错误
        String str1 = list1.get(0); //返回类型就是String

        ArrayList list2 = new ArrayList<String>();
        list2.add("1"); //编译通过
        list2.add(1); //编译通过
        Object object = list2.get(0); //返回类型就是Object

        new ArrayList<String>().add("11"); //编译通过
        new ArrayList<String>().add(22); //编译错误

        String str2 = new ArrayList<String>().get(0); //返回类型就是String
    }
}

通过上面的例子，我们可以明白，类型检查就是针对引用的，谁是一个引用，用这个引用调用泛型方法，就会对这个引用调用的方法进行类型检测，而无关它真正引用的对象。

泛型中参数化类型为什么不考虑继承关系？

在Java中，像下面形式的引用传递是不允许的:

1 2	ArrayList<String> list1 = new ArrayList<object>(); //编译错误 ArrayList<Object> ArrayList<object> list2 = new ArrayList<String>(); //编译错误 ArrayList<String>

我们先看第一种情况，将第一种情况拓展成下面的形式：

ArrayList<object> list1 = new ArrayList<object>();
list1.add(new Object());
list1.add(new Object());
ArrayList<String> list2 = list1; //编译错误

实际上，在第4行代码的时候，就会有编译错误。那么，我们先假设它编译没错。那么当我们使用 list2引用用 get()方法取值的时候，返回的都是 String类型的对象（上面提到了，类型检测是根据引用来决定的），可是它里面实际上已经被我们存放了 Object类型的对象，这样就会有 ClassCastException了。所以为了避免这种极易出现的错误，Java不允许进行这样的引用传递。（这也是泛型出现的原因，就是为了解决类型转换的问题，我们不能违背它的初衷）。

再看第二种情况，将第二种情况拓展成下面的形式：

ArrayList<String> list1 = new ArrayList<String>();
list1.add(new String());
list1.add(new String());

ArrayList<object> list2 = list1; //编译错误

没错，这样的情况比第一种情况好的多，最起码，在我们用 list2取值的时候不会出现 ClassCastException，因为是从 String转换为 Object。可是，这样做有什么意义呢，泛型出现的原因，就是为了解决类型转换的问题。我们使用了泛型，到头来，还是要自己强转，违背了泛型设计的初衷。所以java不允许这么干。再说，你如果又用 list2往里面 add()新的对象，那么到时候取得时候，我怎么知道我取出来的到底是 String类型的，还是 Object类型的呢？

所以，要格外注意，泛型中的引用传递的问题。

3-2.自动类型转换

因为类型擦除的问题，所以所有的泛型类型变量最后都会被替换为原始类型。

既然都被替换为原始类型，那么为什么我们在获取的时候，不需要进行强制类型转换呢？

看下 ArrayList.get()方法：

public E get(int index) {

    RangeCheck(index);

    return (E) elementData[index];

}

可以看到，在 return之前，会根据泛型变量进行强转。假设泛型类型变量为 Date，虽然泛型信息会被擦除掉，但是会将 (E) elementData[index]，编译为 (Date)elementData[index]。所以我们不用自己进行强转。当存取一个泛型域时也会自动插入强制类型转换。假设 Pair类的 value域是 public的，那么表达式：

1	Date Date = pair.value;

也会自动地在结果字节码中插入强制类型转换。

3-3.类型擦除与多态的冲突和解决方法

现在有这样一个泛型类：

class Pair<t> {

    private T value;

    public T getValue() {
        return value;
    }

    public void setValue(T value) {
        this.value = value;
    }
}

然后我们想要一个子类继承它。

class DateInter extends Pair<Date> {

    @Override
    public void setValue(Date value) {
        super.setValue(value);
    }

    @Override
    public Date getValue() {
        return super.getValue();
    }
}

在这个子类中，我们设定父类的泛型类型为 Pair<Date>，在子类中，我们覆盖了父类的两个方法，我们的原意是这样的：将父类的泛型类型限定为 Date，那么父类里面的两个方法的参数都为 Date类型。

public Date getValue() {
    return value;
}

public void setValue(Date value) {
    this.value = value;
}

所以，我们在子类中重写这两个方法一点问题也没有，实际上，从他们的 @Override标签中也可以看到，一点问题也没有，实际上是这样的吗？

分析：实际上，类型擦除后，父类的的泛型类型全部变为了原始类型 Object，所以父类编译之后会变成下面的样子：

class Pair {
    private Object value;

    public Object getValue() {
        return value;
    }

    public void setValue(Object  value) {
        this.value = value;
    }
}

再看子类的两个重写的方法的类型：

@Override
public void setValue(Date value) {
    super.setValue(value);
}
@Override
public Date getValue() {
    return super.getValue();
}

先来分析 setValue方法，父类的类型是 Object，而子类的类型是 Date，参数类型不一样，这如果是在普通的继承关系中，根本就不会是重写，而是重载。

我们在一个main方法测试一下：

public static void main(String[] args) throws ClassNotFoundException {
        DateInter DateInter = new DateInter();
        DateInter.setValue(new Date());
        DateInter.setValue(new Object()); //编译出错
}

如果是重载，那么子类中两个 setValue方法，一个是参数 Object类型，一个是 Date类型，可是我们发现，根本就没有这样的一个子类继承自父类的Object类型参数的方法。所以说，确实是重写了，而不是重载了。

为什么会这样呢？

原因是这样的，我们传入父类的泛型类型是 Date， Pair<Date>，我们的本意是将泛型类变为如下：

class Pair {
    private Date value;
    public Date getValue() {
        return value;
    }
    public void setValue(Date value) {
        this.value = value;
    }
}

然后在子类中重写参数类型为Date的那两个方法，实现继承中的多态。

可是由于种种原因，虚拟机并不能将泛型类型变为 Date，只能将类型擦除掉，变为原始类型 Object。这样，我们的本意是进行重写，实现多态。可是类型擦除后，只能变为了重载。这样，类型擦除就和多态有了冲突。JVM知道你的本意吗？知道！！！可是它能直接实现吗，不能！！！如果真的不能的话，那我们怎么去重写我们想要的 Date类型参数的方法啊。

于是JVM采用了一个特殊的方法，来完成这项功能，那就是桥方法。

首先，我们用 javap -c className的方式反编译下 DateInter子类的字节码，结果如下：

class com.tao.test.DateInter extends com.tao.test.Pair<java.util.Date> {
  com.tao.test.DateInter();
    Code:
       0: aload_0
       1: invokespecial #8                  // Method com/tao/test/Pair."<init>":()V
       4: return

  public void setValue(java.util.Date);  //我们重写了setValue方法
    Code:
       0: aload_0
       1: aload_1
       2: invokespecial #16                 // Method com/tao/test/Pair.setValue:(Ljava/lang/Object;)V
       5: return

  public java.util.Date getValue();    //我们重写了getValue方法
    Code:
       0: aload_0
       1: invokespecial #23                 // Method com/tao/test/Pair.getValue:()Ljava/lang/Object;
       4: checkcast     #26                 // class java/util/Date
       7: areturn

  public java.lang.Object getValue();     //编译时有编译器生成的桥方法
    Code:
       0: aload_0
       1: invokevirtual #28                 // Method getValue:()Ljava/util/Date;去调用我们重写的setValue方法；
       4: areturn

  public void setValue(java.lang.Object);   //编译时有编译器生成的桥方法
    Code:
       0: aload_0
       1: aload_1
       2: checkcast     #26                 // class java/util/Date
       5: invokevirtual #30                 // Method setValue:(Ljava/util/Date;去调用我们重写的setValue方法）V
       8: return
}

从编译的结果来看，我们本意重写 setValue和 getValue方法的子类，竟然有4个方法，其实不用惊奇，最后的两个方法，就是编译器自己生成的桥方法。可以看到桥方法的参数类型都是Object，也就是说，子类中真正覆盖父类两个方法的就是这两个我们看不到的桥方法。而打在我们自己定义的 setvalue和 getValue方法上面的 @Override只不过是假象。而桥方法的内部实现，就只是去调用我们自己重写的那两个方法。

所以，虚拟机巧妙的使用了桥方法，来解决了类型擦除和多态的冲突。

不过，要提到一点，这里面的 setValue和 getValue这两个桥方法的意义又有不同。

setValue方法是为了解决类型擦除与多态之间的冲突。

而 getValue却有普遍的意义，怎么说呢，如果这是一个普通的继承关系：

那么父类的 setValue方法如下：

1
2
3

public Object getValue() {
    return super.getValue();
}

而子类重写的方法是：

1
2
3

public Date getValue() {
    return super.getValue();
}

其实这在普通的类继承中也是普遍存在的重写，这就是协变。

关于协变：。。。。。。

并且，还有一点也许会有疑问，子类中的桥方法 Object getValue()和 Date getValue()是同时存在的，可是如果是常规的两个方法，他们的方法签名是一样的，也就是说虚拟机根本不能分别这两个方法。如果是我们自己编写Java代码，这样的代码是无法通过编译器的检查的，但是虚拟机却是允许这样做的，因为虚拟机通过参数类型和返回类型来确定一个方法，所以编译器为了实现泛型的多态允许自己做这个看起来”不合法”的事情，然后交给虚拟器去区别。

3-4.泛型类型变量不能是基本数据类型

不能用类型参数替换基本类型。就比如，没有 ArrayList<double>，只有 ArrayList<Double>。因为当类型擦除后， ArrayList的原始类型变为 Object，但是 Object类型不能存储 double值，只能引用 Double的值。

3-5.编译时集合的instanceof

1	ArrayList<String> arrayList = new ArrayList<String>();

因为类型擦除之后， ArrayList<String>只剩下原始类型，泛型信息 String不存在了。

那么，编译时进行类型查询的时候使用下面的方法是错误的

1	if( arrayList instanceof ArrayList<String>)

3-6.泛型在静态方法和静态类中的问题

泛型类中的静态方法和静态变量不可以使用泛型类所声明的泛型类型参数

举例说明：

public class Test2<T> {
    public static T one;   //编译错误
    public static  T show(T one){ //编译错误
        return null;
    }
}

因为泛型类中的泛型参数的实例化的时候确定，而静态变量和静态方法不需要使用对象来调用。对象都没有创建，如何确定这个泛型参数是何种类型，所以当然是错误的。

但是要注意区分下面的一种情况：

public class Test2<T> {

    public static <T>T show(T one){ //这是正确的
        return null;
    }
}

因为这是一个泛型方法，在泛型方法中使用的T是自己在方法中定义的 T，而不是泛型类中的T。

Java线程池实现原理及其在美团业务中的实践

发表于 2022-02-28 更新于 2022-03-13 分类于技术 Waline：本文字数： 12k 阅读时长 ≈ 11 分钟

Java线程池实现原理及其在美团业务中的实践

随着计算机行业的飞速发展，摩尔定律逐渐失效，多核CPU成为主流。使用多线程并行计算逐渐成为开发人员提升服务器性能的基本武器。J.U.C提供的线程池：ThreadPoolExecutor类，帮助开发人员管理线程并方便地执行并行任务。了解并合理使用线程池，是一个开发人员必修的基本功。

本文开篇简述线程池概念和用途，接着结合线程池的源码，帮助读者领略线程池的设计思路，最后回归实践，通过案例讲述使用线程池遇到的问题，并给出了一种动态化线程池解决方案。

一、写在前面

1.1 线程池是什么

线程池（Thread Pool）是一种基于池化思想管理线程的工具，经常出现在多线程服务器中，如MySQL。

线程过多会带来额外的开销，其中包括创建销毁线程的开销、调度线程的开销等等，同时也降低了计算机的整体性能。线程池维护多个线程，等待监督管理者分配可并发执行的任务。这种做法，一方面避免了处理任务时创建销毁线程开销的代价，另一方面避免了线程数量膨胀导致的过分调度问题，保证了对内核的充分利用。

而本文描述线程池是JDK中提供的ThreadPoolExecutor类。

当然，使用线程池可以带来一系列好处：

降低资源消耗：通过池化技术重复利用已创建的线程，降低线程创建和销毁造成的损耗。
提高响应速度：任务到达时，无需等待线程创建即可立即执行。
提高线程的可管理性：线程是稀缺资源，如果无限制创建，不仅会消耗系统资源，还会因为线程的不合理分布导致资源调度失衡，降低系统的稳定性。使用线程池可以进行统一的分配、调优和监控。
提供更多更强大的功能：线程池具备可拓展性，允许开发人员向其中增加更多的功能。比如延时定时线程池ScheduledThreadPoolExecutor，就允许任务延期执行或定期执行。

1.2 线程池解决的问题是什么

线程池解决的核心问题就是资源管理问题。在并发环境下，系统不能够确定在任意时刻中，有多少任务需要执行，有多少资源需要投入。这种不确定性将带来以下若干问题：

频繁申请/销毁资源和调度资源，将带来额外的消耗，可能会非常巨大。
对资源无限申请缺少抑制手段，易引发系统资源耗尽的风险。
系统无法合理管理内部的资源分布，会降低系统的稳定性。

为解决资源分配这个问题，线程池采用了“池化”（Pooling）思想。池化，顾名思义，是为了最大化收益并最小化风险，而将资源统一在一起管理的一种思想。

Pooling is the grouping together of resources (assets, equipment, personnel, effort, etc.) for the purposes of maximizing advantage or minimizing risk to the users. The term is used in finance, computing and equipment management.——wikipedia

“池化”思想不仅仅能应用在计算机领域，在金融、设备、人员管理、工作管理等领域也有相关的应用。

在计算机领域中的表现为：统一管理IT资源，包括服务器、存储、和网络资源等等。通过共享资源，使用户在低投入中获益。除去线程池，还有其他比较典型的几种使用策略包括：

内存池(Memory Pooling)：预先申请内存，提升申请内存速度，减少内存碎片。
连接池(Connection Pooling)：预先申请数据库连接，提升申请连接的速度，降低系统的开销。
实例池(Object Pooling)：循环使用对象，减少资源在初始化和释放时的昂贵损耗。

在了解完“是什么”和“为什么”之后，下面我们来一起深入一下线程池的内部实现原理。

二、线程池核心设计与实现

在前文中，我们了解到：线程池是一种通过“池化”思想，帮助我们管理线程而获取并发性的工具，在Java中的体现是ThreadPoolExecutor类。那么它的的详细设计与实现是什么样的呢？我们会在本章进行详细介绍。

2.1 总体设计

Java中的线程池核心实现类是ThreadPoolExecutor，本章基于JDK 1.8的源码来分析Java线程池的核心设计与实现。我们首先来看一下ThreadPoolExecutor的UML类图，了解下ThreadPoolExecutor的继承关系。

图1 ThreadPoolExecutor UML类图

ThreadPoolExecutor实现的顶层接口是Executor，顶层接口Executor提供了一种思想：将任务提交和任务执行进行解耦。用户无需关注如何创建线程，如何调度线程来执行任务，用户只需提供Runnable对象，将任务的运行逻辑提交到执行器(Executor)中，由Executor框架完成线程的调配和任务的执行部分。ExecutorService接口增加了一些能力：（1）扩充执行任务的能力，补充可以为一个或一批异步任务生成Future的方法；（2）提供了管控线程池的方法，比如停止线程池的运行。AbstractExecutorService则是上层的抽象类，将执行任务的流程串联了起来，保证下层的实现只需关注一个执行任务的方法即可。最下层的实现类ThreadPoolExecutor实现最复杂的运行部分，ThreadPoolExecutor将会一方面维护自身的生命周期，另一方面同时管理线程和任务，使两者良好的结合从而执行并行任务。

ThreadPoolExecutor是如何运行，如何同时维护线程和执行任务的呢？其运行机制如下图所示：\

图2 ThreadPoolExecutor运行流程

线程池在内部实际上构建了一个生产者消费者模型，将线程和任务两者解耦，并不直接关联，从而良好的缓冲任务，复用线程。线程池的运行主要分成两部分：任务管理、线程管理。任务管理部分充当生产者的角色，当任务提交后，线程池会判断该任务后续的流转：（1）直接申请线程执行该任务；（2）缓冲到队列中等待线程执行；（3）拒绝该任务。线程管理部分是消费者，它们被统一维护在线程池内，根据任务请求进行线程的分配，当线程执行完任务后则会继续获取新的任务去执行，最终当线程获取不到任务的时候，线程就会被回收。

接下来，我们会按照以下三个部分去详细讲解线程池运行机制：

线程池如何维护自身状态。
线程池如何管理任务。
线程池如何管理线程。

2.2 生命周期管理

线程池运行的状态，并不是用户显式设置的，而是伴随着线程池的运行，由内部来维护。线程池内部使用一个变量维护两个值：运行状态(runState)和线程数量 (workerCount)。在具体实现中，线程池将运行状态(runState)、线程数量 (workerCount)两个关键参数的维护放在了一起，如下代码所示：

1	private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

ctl这个AtomicInteger类型，是对线程池的运行状态和线程池中有效线程的数量进行控制的一个字段，它同时包含两部分的信息：线程池的运行状态 (runState) 和线程池内有效线程的数量 (workerCount)，高3位保存runState，低29位保存workerCount，两个变量之间互不干扰。用一个变量去存储两个值，可避免在做相关决策时，出现不一致的情况，不必为了维护两者的一致，而占用锁资源。通过阅读线程池源代码也可以发现，经常出现要同时判断线程池运行状态和线程数量的情况。线程池也提供了若干方法去供用户获得线程池当前的运行状态、线程个数。这里都使用的是位运算的方式，相比于基本运算，速度也会快很多。

关于内部封装的获取生命周期状态、获取线程池线程数量的计算方法如以下代码所示：

1
2
3

private static int runStateOf(int c)     { return c & ~CAPACITY; } //计算当前运行状态
private static int workerCountOf(int c)  { return c & CAPACITY; }  //计算当前线程数量
private static int ctlOf(int rs, int wc) { return rs | wc; }   //通过状态和线程数生成ctl

ThreadPoolExecutor的运行状态有5种，分别为：

其生命周期转换如下入所示：

图3 线程池生命周期

2.3 任务执行机制

2.3.1 任务调度

任务调度是线程池的主要入口，当用户提交了一个任务，接下来这个任务将如何执行都是由这个阶段决定的。了解这部分就相当于了解了线程池的核心运行机制。

首先，所有任务的调度都是由execute方法完成的，这部分完成的工作是：检查现在线程池的运行状态、运行线程数、运行策略，决定接下来执行的流程，是直接申请线程执行，或是缓冲到队列中执行，亦或是直接拒绝该任务。其执行过程如下：

首先检测线程池运行状态，如果不是RUNNING，则直接拒绝，线程池要保证在RUNNING的状态下执行任务。
如果workerCount < corePoolSize，则创建并启动一个线程来执行新提交的任务。
如果workerCount >= corePoolSize，且线程池内的阻塞队列未满，则将任务添加到该阻塞队列中。
如果workerCount >= corePoolSize && workerCount < maximumPoolSize，且线程池内的阻塞队列已满，则创建并启动一个线程来执行新提交的任务。
如果workerCount >= maximumPoolSize，并且线程池内的阻塞队列已满, 则根据拒绝策略来处理该任务, 默认的处理方式是直接抛异常。

其执行流程如下图所示：

图4 任务调度流程

2.3.2 任务缓冲

任务缓冲模块是线程池能够管理任务的核心部分。线程池的本质是对任务和线程的管理，而做到这一点最关键的思想就是将任务和线程两者解耦，不让两者直接关联，才可以做后续的分配工作。线程池中是以生产者消费者模式，通过一个阻塞队列来实现的。阻塞队列缓存任务，工作线程从阻塞队列中获取任务。

阻塞队列(BlockingQueue)是一个支持两个附加操作的队列。这两个附加的操作是：在队列为空时，获取元素的线程会等待队列变为非空。当队列满时，存储元素的线程会等待队列可用。阻塞队列常用于生产者和消费者的场景，生产者是往队列里添加元素的线程，消费者是从队列里拿元素的线程。阻塞队列就是生产者存放元素的容器，而消费者也只从容器里拿元素。

下图中展示了线程1往阻塞队列中添加元素，而线程2从阻塞队列中移除元素：

图5 阻塞队列

使用不同的队列可以实现不一样的任务存取策略。在这里，我们可以再介绍下阻塞队列的成员：

2.3.3 任务申请

由上文的任务分配部分可知，任务的执行有两种可能：一种是任务直接由新创建的线程执行。另一种是线程从任务队列中获取任务然后执行，执行完任务的空闲线程会再次去从队列中申请任务再去执行。第一种情况仅出现在线程初始创建的时候，第二种是线程获取任务绝大多数的情况。

线程需要从任务缓存模块中不断地取任务执行，帮助线程从阻塞队列中获取任务，实现线程管理模块和任务管理模块之间的通信。这部分策略由getTask方法实现，其执行流程如下图所示：

图6 获取任务流程图

getTask这部分进行了多次判断，为的是控制线程的数量，使其符合线程池的状态。如果线程池现在不应该持有那么多线程，则会返回null值。工作线程Worker会不断接收新任务去执行，而当工作线程Worker接收不到任务的时候，就会开始被回收。

2.3.4 任务拒绝

任务拒绝模块是线程池的保护部分，线程池有一个最大的容量，当线程池的任务缓存队列已满，并且线程池中的线程数目达到maximumPoolSize时，就需要拒绝掉该任务，采取任务拒绝策略，保护线程池。

拒绝策略是一个接口，其设计如下：

1
2
3

public interface RejectedExecutionHandler {
    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}

用户可以通过实现这个接口去定制拒绝策略，也可以选择JDK提供的四种已有拒绝策略，其特点如下：

2.4 Worker线程管理

2.4.1 Worker线程

线程池为了掌握线程的状态并维护线程的生命周期，设计了线程池内的工作线程Worker。我们来看一下它的部分代码：

private final class Worker extends AbstractQueuedSynchronizer implements Runnable{
    final Thread thread;//Worker持有的线程
    Runnable firstTask;//初始化的任务，可以为null
}

Worker这个工作线程，实现了Runnable接口，并持有一个线程thread，一个初始化的任务firstTask。thread是在调用构造方法时通过ThreadFactory来创建的线程，可以用来执行任务；firstTask用它来保存传入的第一个任务，这个任务可以有也可以为null。如果这个值是非空的，那么线程就会在启动初期立即执行这个任务，也就对应核心线程创建时的情况；如果这个值是null，那么就需要创建一个线程去执行任务列表（workQueue）中的任务，也就是非核心线程的创建。

Worker执行任务的模型如下图所示：

图7 Worker执行任务

线程池需要管理线程的生命周期，需要在线程长时间不运行的时候进行回收。线程池使用一张Hash表去持有线程的引用，这样可以通过添加引用、移除引用这样的操作来控制线程的生命周期。这个时候重要的就是如何判断线程是否在运行。

Worker是通过继承AQS，使用AQS来实现独占锁这个功能。没有使用可重入锁ReentrantLock，而是使用AQS，为的就是实现不可重入的特性去反应线程现在的执行状态。

1.lock方法一旦获取了独占锁，表示当前线程正在执行任务中。 2.如果正在执行任务，则不应该中断线程。 3.如果该线程现在不是独占锁的状态，也就是空闲的状态，说明它没有在处理任务，这时可以对该线程进行中断。 4.线程池在执行shutdown方法或tryTerminate方法时会调用interruptIdleWorkers方法来中断空闲的线程，interruptIdleWorkers方法会使用tryLock方法来判断线程池中的线程是否是空闲状态；如果线程是空闲状态则可以安全回收。

在线程回收过程中就使用到了这种特性，回收过程如下图所示：

图8 线程池回收过程

2.4.2 Worker线程增加

增加线程是通过线程池中的addWorker方法，该方法的功能就是增加一个线程，该方法不考虑线程池是在哪个阶段增加的该线程，这个分配线程的策略是在上个步骤完成的，该步骤仅仅完成增加线程，并使它运行，最后返回是否成功这个结果。addWorker方法有两个参数：firstTask、core。firstTask参数用于指定新增的线程执行的第一个任务，该参数可以为空；core参数为true表示在新增线程时会判断当前活动线程数是否少于corePoolSize，false表示新增线程前需要判断当前活动线程数是否少于maximumPoolSize，其执行流程如下图所示：

图9 申请线程执行流程图

2.4.3 Worker线程回收

线程池中线程的销毁依赖JVM自动的回收，线程池做的工作是根据当前线程池的状态维护一定数量的线程引用，防止这部分线程被JVM回收，当线程池决定哪些线程需要回收时，只需要将其引用消除即可。Worker被创建出来后，就会不断地进行轮询，然后获取任务去执行，核心线程可以无限等待获取任务，非核心线程要限时获取任务。当Worker无法获取到任务，也就是获取的任务为空时，循环会结束，Worker会主动消除自身在线程池内的引用。

try {
  while (task != null || (task = getTask()) != null) {
    //执行任务
  }
} finally {
  processWorkerExit(w, completedAbruptly);//获取不到任务时，主动回收自己
}

线程回收的工作是在processWorkerExit方法完成的。

图10 线程销毁流程

事实上，在这个方法中，将线程引用移出线程池就已经结束了线程销毁的部分。但由于引起线程销毁的可能性有很多，线程池还要判断是什么引发了这次销毁，是否要改变线程池的现阶段状态，是否要根据新状态，重新分配线程。

2.4.4 Worker线程执行任务

在Worker类中的run方法调用了runWorker方法来执行任务，runWorker方法的执行过程如下：

1.while循环不断地通过getTask()方法获取任务。 2.getTask()方法从阻塞队列中取任务。 3.如果线程池正在停止，那么要保证当前线程是中断状态，否则要保证当前线程不是中断状态。 4.执行任务。 5.如果getTask结果为null则跳出循环，执行processWorkerExit()方法，销毁线程。

执行流程如下图所示：

图11 执行任务流程

三、线程池在业务中的实践

3.1 业务背景

在当今的互联网业界，为了最大程度利用CPU的多核性能，并行运算的能力是不可或缺的。通过线程池管理线程获取并发性是一个非常基础的操作，让我们来看两个典型的使用线程池获取并发性的场景。

场景1：快速响应用户请求

描述：用户发起的实时请求，服务追求响应时间。比如说用户要查看一个商品的信息，那么我们需要将商品维度的一系列信息如商品的价格、优惠、库存、图片等等聚合起来，展示给用户。

分析：从用户体验角度看，这个结果响应的越快越好，如果一个页面半天都刷不出，用户可能就放弃查看这个商品了。而面向用户的功能聚合通常非常复杂，伴随着调用与调用之间的级联、多级级联等情况，业务开发同学往往会选择使用线程池这种简单的方式，将调用封装成任务并行的执行，缩短总体响应时间。另外，使用线程池也是有考量的，这种场景最重要的就是获取最大的响应速度去满足用户，所以应该不设置队列去缓冲并发任务，调高corePoolSize和maxPoolSize去尽可能创造多的线程快速执行任务。

图12 并行执行任务提升任务响应速度

场景2：快速处理批量任务

描述：离线的大量计算任务，需要快速执行。比如说，统计某个报表，需要计算出全国各个门店中有哪些商品有某种属性，用于后续营销策略的分析，那么我们需要查询全国所有门店中的所有商品，并且记录具有某属性的商品，然后快速生成报表。

分析：这种场景需要执行大量的任务，我们也会希望任务执行的越快越好。这种情况下，也应该使用多线程策略，并行计算。但与响应速度优先的场景区别在于，这类场景任务量巨大，并不需要瞬时的完成，而是关注如何使用有限的资源，尽可能在单位时间内处理更多的任务，也就是吞吐量优先的问题。所以应该设置队列去缓冲并发任务，调整合适的corePoolSize去设置处理任务的线程数。在这里，设置的线程数过多可能还会引发线程上下文切换频繁的问题，也会降低处理任务的速度，降低吞吐量。

图13 并行执行任务提升批量任务执行速度

3.2 实际问题及方案思考

线程池使用面临的核心的问题在于：线程池的参数并不好配置。一方面线程池的运行机制不是很好理解，配置合理需要强依赖开发人员的个人经验和知识；另一方面，线程池执行的情况和任务类型相关性较大，IO密集型和CPU密集型的任务运行起来的情况差异非常大，这导致业界并没有一些成熟的经验策略帮助开发人员参考。

关于线程池配置不合理引发的故障，公司内部有较多记录，下面举一些例子：

Case1：2018年XX页面展示接口大量调用降级：

事故描述：XX页面展示接口产生大量调用降级，数量级在几十到上百。

事故原因：该服务展示接口内部逻辑使用线程池做并行计算，由于没有预估好调用的流量，导致最大核心数设置偏小，大量抛出RejectedExecutionException，触发接口降级条件，示意图如下：

图14 线程数核心设置过小引发RejectExecutionException

Case2：2018年XX业务服务不可用S2级故障

事故描述：XX业务提供的服务执行时间过长，作为上游服务整体超时，大量下游服务调用失败。

事故原因：该服务处理请求内部逻辑使用线程池做资源隔离，由于队列设置过长，最大线程数设置失效，导致请求数量增加时，大量任务堆积在队列中，任务执行时间过长，最终导致下游服务的大量调用超时失败。示意图如下：

图15 线程池队列长度设置过长、corePoolSize设置过小导致任务执行速度低

业务中要使用线程池，而使用不当又会导致故障，那么我们怎样才能更好地使用线程池呢？针对这个问题，我们下面延展几个方向：

1. 能否不用线程池?

回到最初的问题，业务使用线程池是为了获取并发性，对于获取并发性，是否可以有什么其他的方案呢替代？我们尝试进行了一些其他方案的调研：

综合考虑，这些新的方案都能在某种情况下提升并行任务的性能，然而本次重点解决的问题是如何更简易、更安全地获得的并发性。另外，Actor模型的应用实际上甚少，只在Scala中使用广泛，协程框架在Java中维护的也不成熟。这三者现阶段都不是足够的易用，也并不能解决业务上现阶段的问题。

2. 追求参数设置合理性？

有没有一种计算公式，能够让开发同学很简易地计算出某种场景中的线程池应该是什么参数呢？

带着这样的疑问，我们调研了业界的一些线程池参数配置方案：

调研了以上业界方案后，我们并没有得出通用的线程池计算方式。并发任务的执行情况和任务类型相关，IO密集型和CPU密集型的任务运行起来的情况差异非常大，但这种占比是较难合理预估的，这导致很难有一个简单有效的通用公式帮我们直接计算出结果。

3. 线程池参数动态化？

尽管经过谨慎的评估，仍然不能够保证一次计算出来合适的参数，那么我们是否可以将修改线程池参数的成本降下来，这样至少可以发生故障的时候可以快速调整从而缩短故障恢复的时间呢？基于这个思考，我们是否可以将线程池的参数从代码中迁移到分布式配置中心上，实现线程池参数可动态配置和即时生效，线程池参数动态化前后的参数修改流程对比如下：

图16 动态修改线程池参数新旧流程对比

基于以上三个方向对比，我们可以看出参数动态化方向简单有效。

3.3 动态化线程池

3.3.1 整体设计

动态化线程池的核心设计包括以下三个方面：

简化线程池配置：线程池构造参数有8个，但是最核心的是3个：corePoolSize、maximumPoolSize，workQueue，它们最大程度地决定了线程池的任务分配和线程分配策略。考虑到在实际应用中我们获取并发性的场景主要是两种：（1）并行执行子任务，提高响应速度。这种情况下，应该使用同步队列，没有什么任务应该被缓存下来，而是应该立即执行。（2）并行执行大批次任务，提升吞吐量。这种情况下，应该使用有界队列，使用队列去缓冲大批量的任务，队列容量必须声明，防止任务无限制堆积。所以线程池只需要提供这三个关键参数的配置，并且提供两种队列的选择，就可以满足绝大多数的业务需求，Less is More。
参数可动态修改：为了解决参数不好配，修改参数成本高等问题。在Java线程池留有高扩展性的基础上，封装线程池，允许线程池监听同步外部的消息，根据消息进行修改配置。将线程池的配置放置在平台侧，允许开发同学简单的查看、修改线程池配置。
增加线程池监控：对某事物缺乏状态的观测，就对其改进无从下手。在线程池执行任务的生命周期添加监控能力，帮助开发同学了解线程池状态。

图17 动态化线程池整体设计

3.3.2 功能架构

动态化线程池提供如下功能：

动态调参：支持线程池参数动态调整、界面化操作；包括修改线程池核心大小、最大核心大小、队列长度等；参数修改后及时生效。 任务监控：支持应用粒度、线程池粒度、任务粒度的Transaction监控；可以看到线程池的任务执行情况、最大任务执行时间、平均任务执行时间、95/99线等。 负载告警：线程池队列任务积压到一定值的时候会通过大象（美团内部通讯工具）告知应用开发负责人；当线程池负载数达到一定阈值的时候会通过大象告知应用开发负责人。 操作监控：创建/修改和删除线程池都会通知到应用的开发负责人。 操作日志：可以查看线程池参数的修改记录，谁在什么时候修改了线程池参数、修改前的参数值是什么。 权限校验：只有应用开发负责人才能够修改应用的线程池参数。

图18 动态化线程池功能架构

参数动态化

JDK原生线程池ThreadPoolExecutor提供了如下几个public的setter方法，如下图所示：

图19 JDK 线程池参数设置接口

JDK允许线程池使用方通过ThreadPoolExecutor的实例来动态设置线程池的核心策略，以setCorePoolSize为方法例，在运行期线程池使用方调用此方法设置corePoolSize之后，线程池会直接覆盖原来的corePoolSize值，并且基于当前值和原始值的比较结果采取不同的处理策略。对于当前值小于当前工作线程数的情况，说明有多余的worker线程，此时会向当前idle的worker线程发起中断请求以实现回收，多余的worker在下次idel的时候也会被回收；对于当前值大于原始值且当前队列中有待执行任务，则线程池会创建新的worker线程来执行队列任务，setCorePoolSize具体流程如下：

图20 setCorePoolSize方法执行流程

线程池内部会处理好当前状态做到平滑修改，其他几个方法限于篇幅，这里不一一介绍。重点是基于这几个public方法，我们只需要维护ThreadPoolExecutor的实例，并且在需要修改的时候拿到实例修改其参数即可。基于以上的思路，我们实现了线程池参数的动态化、线程池参数在管理平台可配置可修改，其效果图如下图所示：

图21 可动态修改线程池参数

用户可以在管理平台上通过线程池的名字找到指定的线程池，然后对其参数进行修改，保存后会实时生效。目前支持的动态参数包括核心数、最大值、队列长度等。除此之外，在界面中，我们还能看到用户可以配置是否开启告警、队列等待任务告警阈值、活跃度告警等等。关于监控和告警，我们下面一节会对齐进行介绍。

线程池监控

除了参数动态化之外，为了更好地使用线程池，我们需要对线程池的运行状况有感知，比如当前线程池的负载是怎么样的？分配的资源够不够用？任务的执行情况是怎么样的？是长任务还是短任务？基于对这些问题的思考，动态化线程池提供了多个维度的监控和告警能力，包括：线程池活跃度、任务的执行Transaction（频率、耗时）、Reject异常、线程池内部统计信息等等，既能帮助用户从多个维度分析线程池的使用情况，又能在出现问题第一时间通知到用户，从而避免故障或加速故障恢复。

1. 负载监控和告警

线程池负载关注的核心问题是：基于当前线程池参数分配的资源够不够。对于这个问题，我们可以从事前和事中两个角度来看。事前，线程池定义了“活跃度”这个概念，来让用户在发生Reject异常之前能够感知线程池负载问题，线程池活跃度计算公式为：线程池活跃度 = activeCount/maximumPoolSize。这个公式代表当活跃线程数趋向于maximumPoolSize的时候，代表线程负载趋高。事中，也可以从两方面来看线程池的过载判定条件，一个是发生了Reject异常，一个是队列中有等待任务（支持定制阈值）。以上两种情况发生了都会触发告警，告警信息会通过大象推送给服务所关联的负责人。

图22 大象告警通知

2. 任务级精细化监控

在传统的线程池应用场景中，线程池中的任务执行情况对于用户来说是透明的。比如在一个具体的业务场景中，业务开发申请了一个线程池同时用于执行两种任务，一个是发消息任务、一个是发短信任务，这两类任务实际执行的频率和时长对于用户来说没有一个直观的感受，很可能这两类任务不适合共享一个线程池，但是由于用户无法感知，因此也无从优化。动态化线程池内部实现了任务级别的埋点，且允许为不同的业务任务指定具有业务含义的名称，线程池内部基于这个名称做Transaction打点，基于这个功能，用户可以看到线程池内部任务级别的执行情况，且区分业务，任务监控示意图如下图所示：

图23 线程池任务执行监控

3. 运行时状态实时查看

用户基于JDK原生线程池ThreadPoolExecutor提供的几个public的getter方法，可以读取到当前线程池的运行状态以及参数，如下图所示：

图24 线程池实时运行情况

动态化线程池基于这几个接口封装了运行时状态实时查看的功能，用户基于这个功能可以了解线程池的实时状态，比如当前有多少个工作线程，执行了多少个任务，队列中等待的任务数等等。效果如下图所示：

图25 线程池实时运行情况

3.4 实践总结

面对业务中使用线程池遇到的实际问题，我们曾回到支持并发性问题本身来思考有没有取代线程池的方案，也曾尝试着去追求线程池参数设置的合理性，但面对业界方案具体落地的复杂性、可维护性以及真实运行环境的不确定性，我们在前两个方向上可谓“举步维艰”。最终，我们回到线程池参数动态化方向上探索，得出一个且可以解决业务问题的方案，虽然本质上还是没有逃离使用线程池的范畴，但是在成本和收益之间，算是取得了一个很好的平衡。成本在于实现动态化以及监控成本不高，收益在于：在不颠覆原有线程池使用方式的基础之上，从降低线程池参数修改的成本以及多维度监控这两个方面降低了故障发生的概率。希望本文提供的动态化线程池思路能对大家有帮助。

使用java8实现List中对象属性的去重

java8类型互转

List< Integer >、int[ ]、Integer[ ]相互转换

int[ ] 转 List< Integer >

int[ ] [ ] 转 List< List < Integer > >

int[ ] 转 Integer[ ]

int[ ] [ ]转 Integer[ ] [ ]

Integer[ ] 转 List< Integer >

Integer[ ] [ ]转 List< List < Integer > >

Integer[ ] 转 int[ ]

Integer[ ] [ ]转 int[ ] [ ]

List< Integer > 转 int[ ]

List< List < Integer > > 转 int[ ] [ ]

List< Integer > 转 Integer[ ]

List< List < Integer > > 转 Integer[ ] [ ]

List< Character >、char[ ]、Character[ ]相互转换

char[ ] 转 List< Character >

char[ ] [ ] 转 List< List < Character > >

char[ ] 转 Character[ ]

char[ ] [ ]转 Character[ ] [ ]

Character[ ] 转 List< Character >

Character[ ] [ ]转 List< List < Character > >

Character[ ] 转 char[ ]

Character[ ] [ ]转 char[ ] [ ]

List< Character > 转 char[ ]

List< List < Character > > 转 char[ ] [ ]

List< Character > 转 Character[ ]

List< List < Character > > 转 Character[ ] [ ]

注释书写规范

一、类和接口的注释

二、方法与复杂逻辑的注释

建议

Java内存模型2

Java 内存模型

工作内存和主内存

Java 内存操作协议

内存模型三大特性

1、原子性

2、可见性

3、有序性

volatile 的应用

ThreadLocal 的应用及源码解析

ThreadLocal 的常见应用

ThreadLocal 的实现原理

ThreadLocal 在 Spring 中的使用

ThreadLocal 在 Mybatis 中的使用

J.U.C 包的实际应用

线程池 ThreadPoolExecutor

Executors 提供的 4 种线程池

如何配置线程池

线程池的实际应用

BlockingQueue

核心方法

主要实现类

CAS 指令和原子类（应用比较多的就是计数器）

java 名词

“吃人”的那些Java名词：对象、引用、堆、栈️

一、对象和引用

二、堆、栈、堆栈

三、特殊的“对象”

Java泛型类型擦除以及类型擦除带来的问题

1.Java泛型的实现方法：类型擦除

1-1.通过两个例子证明Java类型的类型擦除

2.类型擦除后保留的原始类型

3.类型擦除引起的问题及解决方法

3-1.先检查，再编译以及编译的对象和引用传递问题

3-2.自动类型转换

3-3.类型擦除与多态的冲突和解决方法

3-4.泛型类型变量不能是基本数据类型

3-5.编译时集合的instanceof

3-6.泛型在静态方法和静态类中的问题

一、写在前面

1.1 线程池是什么

1.2 线程池解决的问题是什么

二、线程池核心设计与实现

2.1 总体设计

2.2 生命周期管理

2.3 任务执行机制

三、线程池在业务中的实践

3.1 业务背景