关于java:JAVA多线程并发编程避坑指南

作者：京东批发 肖朋伟

一、前言

开发过程中，多线程的利用场景堪称非常宽泛，能够充分利用服务器资源，进步程序处理速度。咱们通常也会应用池化技术，去防止频繁创立和销毁线程。

本篇旨在基于编码标准、工作中积攒的研发教训等，整顿在多线程开发的过程中须要留神的局部，比方不思考线程池参数、线程平安、死锁等问题，将会存在潜在极大的危险。并且对其进行根因剖析，防止每天踩一坑，坑坑不一样。

二、多线程并发场景有哪些坑？

1、“不正确的创立”线程池

惯例来说，线程资源必须通过线程池提供，不容许在利用中自行显式创立线程，京东 JAVA 代码标准也明确示意“线程资源必须通过线程池提供，不容许在利用中自行显式创立线程”，然而创立线程池的形式也有很多种，不能滥用。

常见创立线程池形式如：通过 JDK 提供的 ThreadPoolExecutor、ScheduledThreadPoolExecutor 以及 JDK 7 开始引入的 ForkJoinPool 创立，还有更不便的 Executors 类以及 spring 提供的 ThreadPoolTaskExecutor 等。其关系如下图：

Executors 的 newFixedThreadPool、newScheduledThreadPool、newSingleThreadExecutor、newCachedThreadPool 办法在底层都是用的 ThreadPoolExecutor 实现的。尽管更加不便，但也减少了危险，如果不分明其相干实现，在特定场景可能导致很重大的问题，所以开发标准中，会严格禁用此类用法。它们的弊病如下：

（1）FixedThreadPool 和 SingleThreadPool 容许的申请工作队列长度为 Integer.MAX_VALUE，可能会沉积大量的申请，从而导致 OOM。

（2）CachedThreadPool 和 ScheduledThreadPool 容许的创立线程数量为 Integer.MAX_VALUE，可能会创立大量的线程，从而导致 OOM。

2、线程池“参数设置不合理”

下面提到了 工作队列 和 最大线程数的重要性，上面通过 ThreadPoolExecutor 介绍线程池其余外围参数，都应该依据场景合理配置，具体如下：

留神在设置工作队列时，须要思考有界和无界队列，应用有界队列时，留神线程池满了后，被回绝的工作如何解决。应用无界队列时，须要留神如果工作的提交速度大于线程池的处理速度，可能会导致内存溢出。

对于回绝策略，首先要明确的一点是“回绝策略的执行线程是提交工作的线程，而不是子线程”。JDK 的 ThreadPoolExecutor 提供了 4 种回绝策略：

对于自定义回绝策略，不同场景应抉择相应的回绝策略，抛开利用场景讲技术会显得红润，大家能够参考常见技术框架的解决形式：

相干拓展：

置信大多数京东开发者都遇到过，JSF 依赖服务触发回绝策略的景象，即抛出线程回绝异样。这是当 Provider 的 业务线程池满了，无可用线程池的时候，会返回一个异样给 Consumer，告知 Consumer 该 Provider 线程池已耗尽。如图：

当然这种异样场景，根本原因并非线程池配置不合理，应该关注服务提供方性能瓶颈，对于线程池的配置，其实没用一个对立或者可举荐的配置能够套用。对于 JSF 业务线程池，默认应用的是伸缩无队列线程池，其也提供了配置形式。

3、部分线程池“应用后不销毁回收”

线程会耗费贵重的系统资源，比方内存等，所以是很不举荐应用部分线程池（未事后创立的线程池，用完就能够销毁，下次用时还会创立）的；然而如果某些非凡场景的确应用了部分线程池，那么应该在用完后，被动销毁。被动销毁线程池次要有两种形式：

为了更深刻的了解两个问题：

（1）到底是否所有部分创立的线程池都须要被动销毁？

（2）为什么 Dubbo 中的线程回绝策略 AbortPolicyWithReport 应用了 Executors.newSingleThreadExecutor()，并且没有被动销毁动作？

咱们须要从 GC 角度进行剖析。要晓得对象什么时候死亡，咱们须要先晓得 JVM 的 GC 是如何判断对象是能够回收的。JAVA 是通过可达性算法来来判断对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜寻，搜寻所走过的门路称为援用链，当一个对象到 GC Roots 没有任何援用链相连时，则证实此对象是不可用的。

对于线程池而言，在 ThreadPoolExecutor 类中具备非动态外部类 Worker，用于示意以后线程池中的线程，因为非动态外部类对象具备内部包装类对象的援用，所以当存在线程 Worker 对象时，线程池不会被 GC 回收。也就是说，线程池没有援用，且线程池内没有存活线程时，才是能够被 GC 回收的。应留神的是线程池的外围线程默认是始终存活的，除非外围线程数为 0 或者设置了 allowCoreThreadTimeOut 容许外围打消闲暇时销毁。

咱们对 Executors 创立的三种线程池进行比拟：

三种类型的线程池与 GC 关系：

（1）CachedThreadPool：没有外围线程，且线程具备超时工夫，可见在其援用隐没后，期待工作运行完结且所有线程闲暇回收后，GC 开始回收此线程池对象；

（2）FixedThreadPool：外围线程数及最大线程数均为 nThreads，并且在默认 allowCoreThreadTimeOut 为 false 的状况下，其援用隐没后，外围线程即便闲暇也不会被回收，故 GC 不会回收该线程池；

（3）SingleThreadExecutor：在创立时理论返回的是 FinalizableDelegatedExecutorService 类的对象，该类从新了 finalize() 函数执行线程池的销毁，该对象持有 ThreadPoolExecutor 对象的援用，但 ThreadPoolExecutor 对象并不援用 FinalizableDelegatedExecutorService 对象，这使得在 FinalizableDelegatedExecutorService 对象的内部援用隐没后，GC 将会对其进行回收，触发 finalize 函数，而该函数仅仅简略的调用 shutdown 函数敞开线程，在所有以后的工作执行实现后，回收线程池中线程，则 GC 可回收线程池对象

所以论断是：CachedThreadPool 及 SingleThreadExecutor 的对象在不显式销毁时，且其对象援用隐没的状况下，能够被 GC 回收；FixedThreadPool 对象在不显式销毁，且其对象援用隐没的状况下不会被 GC 回收，会呈现内存泄露。因而无论应用什么线程池，应用结束后均调用 shutdown 是一个较为平安的编程习惯。

4、线程池解决“刚启动时效率低”

默认状况下，即便是外围线程也只能在新工作达到时才创立和启动。对于 ThreadPoolExecutor 线程池能够应用 prestartCoreThread（启动一个外围线程）或 prestartAllCoreThreads（启动全副外围线程）办法来提前启动外围线程。

5、“不合理的应用共享线程池”

提交异步工作，不指定线程池，存在最次要问题是非核心业务占用线程资源，可能会导致外围业务收影响。因为公共线程池的最大线程数、队列大小、回绝策略都比拟激进，可能引发各种问题，常见场景如下：

（1）CompleteFuture 提交异步工作，不指定线程池。

CompleteFuture 的 supplyAsync 等以 *Async 为结尾的办法，会应用多线程异步执行。能够留神到的是，它也容许咱们不携带多线程提交工作的执行线程池参数，这个时候是默认应用的 ForkJoinPool.commonPool()。

ForkJoinPool 最适宜的是计算密集型的工作，如果存在 I/O，线程间同步，sleep() 等会造成线程长时间阻塞的状况时，最好配合应用 ManagedBlocker。ForkJoinPool 默认线程数取决于 parallelism 参数为：CPU 处理器核数 -1，也容许通批改 Java 零碎属性 “java.util.concurrent.ForkJoinPool.common.parallelism” 进行自定义配置。

（2）JDK 8 引入的汇合框架的并行流 Parallel Stream。

Parallel Stream 也是应用的 ForkJoinPool.commonPool()，但有一点区别是：Parallel Stream 的主线程 ( 提交工作的线程）是会去参加解决的；比方 8 外围的机器执行 Parallel Stream 是有 8 个线程，而 CompleteFuture 提交的工作只有 7 个线程解决。不倡议应用是统一的。

（3）@Async 提交异步工作，不指定线程池。

SpringBoot 2.1.9 之前版本应用 @Async 不指定 Executor 会应用 SimpleAsyncTaskExecutor，该线程池默认来一个工作创立一个线程，若零碎中一直的创立线程，最终会导致系统占用内存过高，引发 OutOfMemoryErro r 谬误。SpringBoot 2.1.0 之后版本引入了 TaskExecutionAutoConfiguration，其应用 ThreadPoolTaskExecutor 作为 默认 Executor，通过 TaskExecutionProperties.Pool 能够看到其配置默认外围线程数：8，最大线程数：Integet.MAX\_VALUE，队列容量是：Integet.MAX\_VALUE，闲暇线程保留工夫：60s，线程池回绝策略：AbortPolicy。

尽管能够通实现 AsyncConfigurer 接口等形式，自行配置线程池参数，但仍不倡议应用公共线程池。

6、主线程“等待时间不合理”

（1）应尽量避免应用 CompletableFuture.join()，Future.get() 这类不带有超时工夫的阻塞主线程操作。

（2）for 循环应用 future.get(long timeout, TimeUnit unit)。此办法容许咱们去设置超时工夫，然而如果主线程串行获取的话，下一个 future.get 办法的超时工夫，是从第一个 get() 完结后开始计算的，所以会导致超时工夫不合理。

7、提交工作“不思考子线程超时工夫”

（1）主线程 Future.get 尽管超时，然而子线程仍然在执行？

比方当通过 ExecutorService 提交一个 Callable 工作的时候，会返回一个 Future 对象，Future 的 get(long timeout, TimeUnit unit) 办法时，如果呈现超时，则会抛出 java.util.concurrent.TimeoutException；然而，此时 Future 实例所在的线程并没有中断执行，只是主线程不期待了，也就是以后线程的 status 仍然是 NEW 值为 0 的状态，所以当大量超时，可能就会将线程池打满。

提到中断子线程，会想到 future.cancel(true)。那么咱们真的能够中断子线程吗？首先 Java 无奈间接其余线程的，如果非要实现此性能，也只能通过 interrupt 设置标记位，子线程执行到中间环节去查看标记位，辨认到中断后做后续解决。了解一个关键点，interrupt() 办法仅仅是扭转一个标记位的值而已，和线程的状态并没有必然的分割。

（2）子线程的工作都应该有一个正当的超时工夫。

比方子线程调用 JSF/ HTTP 接口等，肯定要查看超时工夫配置是否正当。

8、并发执行“线程不平安”操作

多线程操作同一对象应思考线程安全性。常见场景比方 HashMap 应该换成 ConcurrentHashMap；StringBuilder 应该换成 StringBuffer 等。

9、“不思考线程变量”的传递

提交到线程池执行的异步工作，切换了线程，子线程在执行时，获取不到主线程变量中存储的信息，常见场景如下：

（1）相似 BU 等，为了缩小参数透传，可能存在了 ThreadLocal 外面；

（2）客户的登录状态，LoginContext 等信息，个别是线程变量；

如果解决此问题，能够参考 Transmittable-Thread-Local 中间件提供的解决方案等。

10、并发会“增大呈现死锁的可能性”

多线程不只是程序中提交到线程池执行，比方打到同一容器的 http 申请自身就是多线程，任何多线程操作都有死锁危险。应用业务线程池的并发操作须要更加留神，因为更容易裸露进去“死锁”这个问题。

比方 Mysql 事务隔离级别为 RR 时，间隙锁可能导致死锁问题。间隙锁是 Innodb 在可反复读提交下为了解决幻读问题时引入的锁机制，在执行 update、delete、select … for update 等语句时，存在以下加间隙锁状况：

（1）有索引，当更新的数据存在时，只会锁定以后记录；更新的不存在时，间隙锁会向左找第一个比以后索引值小的值，向右找第一个比以后索引值大的值（没有比以后索引值大的数据时，是 supremum pseudo-record，能够了解为锁到无穷大）。

（2）无索引，全表扫描，如果更新的数据不存在，则会依据主键索引对所有间隙加锁。

当并发执行数据库事务（事务内先更新，后新增操作），当更新的数据不存在时，会加间隙锁，而后执行新增数据须要其余事务开释在此区间的间隙锁，则可能导致死锁产生；如果是全表扫描，问题可能更重大。

11、“不思考申请过载”

最初，咱们设置了正当的参数，也留神优化了各种场景问题，终于能够大胆应用多线程了。也肯定要思考对上游带来的影响，比方数据库申请并发量增长，占用 JDBC 数据库连贯、给依赖 RPC 服务带来性能压力等。

参考文章链接：

•http://www.kailing.pub/article/index/arcid/255.html

•https://blog.csdn.net/sinat_15946141/article/details/107951917

•https://segmentfault.com/a/1190000016461183?utm_source=tag-newest

•https://blog.csdn.net/v123411739/article/details/106609583/

•https://blog.csdn.net/whzhaochao/article/details/126032116

•https://www.kuangstudy.com/bbs/1407940516238090242