记录一次线程池使用不当，导致进程一直等待的问题

2020-09-12 1138

感觉写这个标题，明眼人一看可能觉得这不就是死锁吗？但是今天说的情况还不是真正意义上的死锁，顶多算是宏观意义上的死锁。而且这个情况使用jstack工具查看不到死锁的信息。

使用线程池不当，导致的线程相互等待

今天的例子

public class Test {

    static ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Future<String> outterFuture = threadPoolExecutor.submit(() -> {

            Future<String> innerFuture = threadPoolExecutor.submit(() -> {
                System.out.println("inner finish");
                return "inner finish";
            });
            String s = innerFuture.get();

            System.out.println("outter get inner finish:" + s);

            System.out.println("outter finish");
            return "outter finish";
        });
        String s = outterFuture.get();
        System.out.println("process get outter finish:" + s);
    }
}

意思就是提交了一个线程1，线程1里面提交了一个线程2，线程1等待线程2的结果。可能有些人很明显就看出问题了，当然这个是简化后的结果，实际情况线程池使用可能比这隐晦的多。执行这个方法，直接就会导致两个线程相互等待。

jstack现象

2020-09-12 09:52:41
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode):

"Attach Listener" #11 daemon prio=9 os_prio=0 tid=0x00007fbf38001000 nid=0x37c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"pool-1-thread-1" #10 prio=5 os_prio=0 tid=0x00007fbf9819c800 nid=0x7932 waiting on condition [0x00007fbf77af9000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006c8e08478> (a java.util.concurrent.FutureTask)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
	at java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at Test.lambda$main$1(Test.java:24)
	at Test$$Lambda$1/1418481495.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:748)

"Service Thread" #9 daemon prio=9 os_prio=0 tid=0x00007fbf980d2000 nid=0x7930 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=0 tid=0x00007fbf980c7000 nid=0x792f waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007fbf980c4800 nid=0x792e waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007fbf980c3000 nid=0x792d waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007fbf980c0000 nid=0x792c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007fbf980be800 nid=0x792b runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007fbf9808b800 nid=0x792a in Object.wait() [0x00007fbf84371000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000006c8e01a60> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
	- locked <0x00000006c8e01a60> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007fbf98086800 nid=0x7929 in Object.wait() [0x00007fbf84472000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000006c8e0f950> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
	- locked <0x00000006c8e0f950> (a java.lang.ref.Reference$Lock)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007fbf98008800 nid=0x791e waiting on condition [0x00007fbf9e635000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000006c8e177b8> (a java.util.concurrent.FutureTask)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
	at java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at Test.main(Test.java:31)

"VM Thread" os_prio=0 tid=0x00007fbf9807f000 nid=0x7928 runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fbf9801d800 nid=0x791f runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fbf9801f800 nid=0x7920 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fbf98021800 nid=0x7921 runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fbf98023000 nid=0x7922 runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00007fbf98025000 nid=0x7923 runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00007fbf98027000 nid=0x7925 runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00007fbf98028800 nid=0x7926 runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00007fbf9802a800 nid=0x7927 runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007fbf980d5000 nid=0x7931 waiting on condition 

JNI global references: 201

通过jstack没有主动发现死锁情况。由于真实情况业务和组件的线程很多更难判断。

线程池参数解析

下面是ThreadPoolExecutor线程池参数最对的构造函数

public ThreadPoolExecutor(int corePoolSize,
                              int maximumPoolSize,
                              long keepAliveTime,
                              TimeUnit unit,
                              BlockingQueue<Runnable> workQueue,
                              ThreadFactory threadFactory,
                              RejectedExecutionHandler handler) {
       ......
    }

函数的参数含义如下（具体细节请自行百度）：

corePoolSize：线程池核心线程数
maximumPoolSize：线程池最大数
keepAliveTime：空闲线程存活时间
unit：时间单位
workQueue：线程池所使用的缓冲队列
threadFactory：线程池创建线程使用的工厂
handler：线程池对拒绝任务的处理策略

原因分析1

例子中定义的核心线程数和最大线程数都是1，说明线程池只能同时有一个线程在执行。然后定义了一个线程队列存放待执行的线程。问题就在于，提交线程outter，该线程就占据了核心线程数1，然后线程outter里面提交了一个线程inner，并等待线程inner的执行结果。而线程inner一直没执行，因为线程inner需要等待线程池当前执行线程数小于最大线程数之后才能，在队列中等待的线程。导致了线程outter占据了线程池能执行任务的最大数量，等待线程inner的结果，线程inner等待线程池来执行而未返回结果。

原因分析2

其实通过jstack 的日志也是能发现问题的，如名为Reference Handler和名为Finalizer的线程中，自生waiting on和locked的条件是相同的，就是自己等自己，出现了一直等待。

死锁

这里先温习一下死锁的情况。

死锁条件

互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占用者主动释放
请求和保持，即当资源的请求者在请求其他的资源的同时保持对原有资源的占有
循环等待，即存在一个等待队列: P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。

死锁例子

public class DeadLock implements Runnable{

    private static Object obj1 = new Object();
    private static Object obj2 = new Object();
    private boolean flag;

    public DeadLock(boolean flag){
        this.flag = flag;
    }

    @Override
    public void run(){
        System.out.println(Thread.currentThread().getName() + "运行");

        if(flag){
            synchronized(obj1){
                System.out.println(Thread.currentThread().getName() + "已经锁住obj1");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized(obj2){
                    // 执行不到这里
                    System.out.println("1秒钟后，"+Thread.currentThread().getName()
                            + "锁住obj2");
                }
            }
        }else{
            synchronized(obj2){
                System.out.println(Thread.currentThread().getName() + "已经锁住obj2");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized(obj1){
                    // 执行不到这里
                    System.out.println("1秒钟后，"+Thread.currentThread().getName()
                            + "锁住obj1");
                }
            }
        }
    }

    public static void main(String[] args) {

        Thread t1 = new Thread(new DeadLock(true), "线程1");
        Thread t2 = new Thread(new DeadLock(false), "线程2");

        t1.start();
        t2.start();
    }
}

jstack现象

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode):

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000003866000 nid=0x2ffc waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"线程2" #12 prio=5 os_prio=0 tid=0x000000001e6b8000 nid=0x20e4 waiting for monitor entry [0x000000001f8bf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.wp.security.springboot.DeadLock.run(DeadLock.java:42)
        - waiting to lock <0x000000076b47b980> (a java.lang.Object)
        - locked <0x000000076b47b990> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

"线程1" #11 prio=5 os_prio=0 tid=0x000000001eec8800 nid=0x11d8 waiting for monitor entry [0x000000001f7bf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.wp.security.springboot.DeadLock.run(DeadLock.java:28)
        - waiting to lock <0x000000076b47b990> (a java.lang.Object)
        - locked <0x000000076b47b980> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x000000001e607000 nid=0x3888 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001e57c800 nid=0x1a1c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x000000001e56f000 nid=0x37b4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x000000001e56e800 nid=0x1eb0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001e56a800 nid=0x2298 runnable [0x000000001e9be000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x000000076b4cf910> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x000000076b4cf910> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:61)

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000001cf8a000 nid=0x1e84 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001cf74000 nid=0x2330 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001cf4e800 nid=0x4168 in Object.wait() [0x000000001e2bf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b208ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x000000076b208ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:212)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000003956000 nid=0x3478 in Object.wait() [0x000000001e1bf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b206bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x000000076b206bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x000000001cf27000 nid=0x47a4 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000387b800 nid=0x1ec8 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000387d000 nid=0x47a0 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000387e800 nid=0x3364 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000003881800 nid=0x4848 runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001e5e5800 nid=0x1318 waiting on condition

JNI global references: 12


Found one Java-level deadlock:
=============================
"线程2":
  waiting to lock monitor 0x000000001cf4b598 (object 0x000000076b47b980, a java.lang.Object),
  which is held by "线程1"
"线程1":
  waiting to lock monitor 0x000000001cf4ded8 (object 0x000000076b47b990, a java.lang.Object),
  which is held by "线程2"

Java stack information for the threads listed above:
===================================================
"线程2":
        at com.wp.security.springboot.DeadLock.run(DeadLock.java:42)
        - waiting to lock <0x000000076b47b980> (a java.lang.Object)
        - locked <0x000000076b47b990> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)
"线程1":
        at com.wp.security.springboot.DeadLock.run(DeadLock.java:28)
        - waiting to lock <0x000000076b47b990> (a java.lang.Object)
        - locked <0x000000076b47b980> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

这里看线程1和线程2中的waiting to lock 和locked 后的资源，一目了然。而且jstack结尾也有提示发现死锁Found one Java-level deadlock

为什么jstack不能主动发现死锁

在线程池的例子中并没有明确的是通过占用锁，导致死锁，所以这个例子中不算死锁。而死锁的例子很明确，就是两个线程相互抢占锁导致的，所以这个就是死锁，在jstack中会发现死锁。

如何判断类似于死锁的相互等待

出现类似这种情况，在jstack不提示的情况下，通过分析业务逻辑的线程确实难以发现问题所在。我对比了一下这两个例子的线程dump，注意到waiting on、waiting to lock、parking to wait for、locked这几个关键字。在百度查了一下。

waiting on condition表示非Object.wait的条件等待，比如说你调用了sleep，park等操作
parking to wait for 就是调用了park动作了
waiting to lock 就是等待一个锁对象

死锁的例子中jstack之所以能检测出死锁，我猜估计他是通过waiting to lock 和 locked 判断，也就是真正意义上的死锁。而waiting on和locked，是今天讨论线程池中线程等待出现的情况。如果想判断线程是否出现这种类似于死锁的相互等待和死锁，其实需要判断所有的waiting和locked条件中是否相同。

微信关注我们

原文链接：https://my.oschina.net/MyoldTime/blog/4559573

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Dubbo-go 应用维度注册模型

Dubbo 3.0 将至。其最重要的一点就是服务自省，其基础即是应用维度的注册模型，作为目前与 Dubbo 在功能上完全对齐的 Dubbo-go，已于本年【2020 年】7 月份发布了其 v1.5.0 版本，实现了该模型，为年底实现与 Dubbo 3.0 对齐的新版本奠定了基础。 Dubbo-go 作为 Dubbo 的 Go 语言版本，因跨语言之故，二者针对同一模型的实现必然有较大差异，故本文注重讨论 Dubbo-go 社区自身对该模型的理解和实现，以及其与 Dubbo 之间的差异。 1 引语在 v1.5 以前，Dubbo-go 注册模型都是以服务为维度的，直观的理解可认为其是接口维度。譬如注册信息，按照服务维度模型其示例如下： "com.xxx.User":[ {"name":"instance1", "ip":"127.0.0.1", "metadata":{"timeout":1000}}, {"name":"instance2", "ip":"127.0.0.2", "metadata":{"timeout":2000}}, {"name":"instance3", "ip...

2020-09-11

772

随着国内互联网市场竞争白热化，开发者转攻海外市场，期望能从尚未饱和的海外市场获取流量增长。据艾媒咨询（iMedia）《2020年中国APP出海市场现状与竞争格局专题研究报告》显示，中国移动互联网企业出海以游戏、电商、工具类应用为主。这些领域在中国市场较为成熟，用户规模触及天花板，市场上巨头企业占据大部分市场份额，因此更多企业将发展机遇逐步投向了海外。这其中不乏许多出海的“先行者”，在海外拓展中积累了丰富的实战经验。但对于刚踏上出海这条“航线”的新起航者而言，在对目标区域语言环境，文化习俗，法律合规和用户习惯都不熟悉的情况下，出海之路也并非一帆风顺：如何让产品更好的融入本地文化，为用户所接受和喜爱，如何规避本地合规风险，为产品运营营造良好的合规环境，背后蕴含了许多对市场与用户的洞察和思考。 9月11日，作为华为开发者大会2020的议题之一，华为联合合作伙伴共同举办在东莞松山湖举行“全球生态—中国出海领袖峰会”。本次峰会上，华为正式联合网易、完美世界、Cocos、宝宝巴士、网龙网络、环球易购、Funplus、小熊博望、小影科技、欧普、飞书深诺、Testin等12家合作伙伴发起HMS出海生...

2020-09-12

619

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

记录一次线程池使用不当，导致进程一直等待的问题

使用线程池不当，导致的线程相互等待

今天的例子

jstack现象

线程池参数解析

原因分析1

原因分析2

死锁

死锁条件

死锁例子

jstack现象

为什么jstack不能主动发现死锁

如何判断类似于死锁的相互等待

Dubbo-go 应用维度注册模型

HMS 出海生态联盟成立，华为携手合作伙伴为出海开发者服务

相关文章

发表评论

资源下载

优质分享App

腾讯云软件源

Spring

Rocky Linux

欢迎您来访！