dubbo线程

[wujinbiao94]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.
• [x] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

• Dubbo version: 2.6.6
• Operating System version: centos
• Java version: 1.8

Steps to reproduce this issue

1. 服务出现线程池打满的情况打印了Dubbo的堆栈
   2.但是出现的线程都是等待任务
   3.配置了dubbo的业务线程是1000，qps大概是1500+

Expected Result

不应该是线程池满了，但是并发量比较高

Actual Result

打印的dubbo线程的状态都是这种，我查到是说现在这个状态都是空闲状态

"DubboServerHandler-xxx-thread-234" Id=322 WAITING on java.util.concurrent.SynchronousQueue$TransferStack@53452753
    at sun.misc.Unsafe.park(Native Method)
    -  waiting on java.util.concurrent.SynchronousQueue$TransferStack@53452753
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
    at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
    at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

我需要调整线程数吗，还是有什么其他的优化的方法，谢谢

[tswstarplanet]

一个请求处理时间长吗？

[wujinbiao94]

一个请求处理时间长吗？

正常情况下一个请求的时间不长，10ms以下吧，由于其他原因可能会波动到30ms左右

不知道是啥原因，方法处理的时间比较短，但是总的耗时比较长，不知道是不是线程的问题，
用pinpoint监控显示等待时间比较长，目前不清楚是什么原因

qps比较高大概在1500，我设置的dubbo业务线程池是1000，我提高这个可以优化吗，目前没有尝试

[tswstarplanet]

1000已经很大了，不建议再增加

[tswstarplanet]

建议线程数不要超800，另外检查下自己程序有没有问题

[keith-java]

我在生产环境遇到了同样的问题，QPS的量大概在3k，多个节点都出现了可用性降低告警。在系统异常期间jstack thread dump日志。统计DubboServerHandler线程数量是800（与配置线程大小一致），但是线程的都是WAITING状态。但是系统log日志又Thread pool is EXHAUSTED异常。`"DubboServerHandler-xxxxxxxxxxxxxxxxxxx:20880-thread-736" - Thread t@875
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <7728d8a0> (a java.util.concurrent.SynchronousQueue$TransferStack)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Locked ownable synchronizers:
- None`

按照我的理解，这个线程堆栈表示在等待任务。实际上导出这个thread_dump的时候，业务日志中是有抛出dubbo的连接池满的情况。我们用的dubbo的dispather策略是all。这个两个现象完全是矛盾的。让我很疑惑。

[wujinbiao94]

我在生产环境遇到了同样的问题，QPS的量大概在3k，多个节点都出现了可用性降低告警。在系统异常期间jstack thread dump日志。统计DubboServerHandler线程数量是800（与配置线程大小一致），但是线程的都是WAITING状态。但是系统log日志又Thread pool is EXHAUSTED异常。`"DubboServerHandler-xxxxxxxxxxxxxxxxxxx:20880-thread-736" - Thread t@875
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)

• parking to wait for <7728d8a0> (a java.util.concurrent.SynchronousQueue$TransferStack)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
  at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
  at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
  at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924)
  at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

Locked ownable synchronizers:

• None`

按照我的理解，这个线程堆栈表示在等待任务。实际上导出这个thread_dump的时候，业务日志中是有抛出dubbo的连接池满的情况。我们用的dubbo的dispather策略是all。这个两个现象完全是矛盾的。让我很疑惑。

我也不是很理解

[keith-java]

后来我重新对接口进行压测，我得出一个结论就是，线程栈的日志应该是不能反应流量峰值那一刻的情况，虽然并发量一直在持续（或者说系统可用性一直在降低），但是实际上峰值可能已经过去。之所以得出这个结论是因为，我在并发量的极限值（并发量错误率2%）以下压测，导出线程栈情况，也会出现线程状态全部是等待的情况。按照我的理解，这只能说明在并发量极限值以下系统的处理能力很强。

[keith-java]

一个请求处理时间长吗？

正常情况下一个请求的时间不长，10ms以下吧，由于其他原因可能会波动到30ms左右

不知道是啥原因，方法处理的时间比较短，但是总的耗时比较长，不知道是不是线程的问题，
用pinpoint监控显示等待时间比较长，目前不清楚是什么原因

qps比较高大概在1500，我设置的dubbo业务线程池是1000，我提高这个可以优化吗，目前没有尝试

我从dubbo中的源码中看到了在linux的系统变量user.home路径下有线程池耗尽时的线程日志，这个日志是dubbo执行拒绝策略的时候导出的线程堆栈，你可以上服务器看看。我已经解决了这个问题。

[wujinbiao94]

一个请求处理时间长吗？

正常情况下一个请求的时间不长，10ms以下吧，由于其他原因可能会波动到30ms左右
不知道是啥原因，方法处理的时间比较短，但是总的耗时比较长，不知道是不是线程的问题，
用pinpoint监控显示等待时间比较长，目前不清楚是什么原因
qps比较高大概在1500，我设置的dubbo业务线程池是1000，我提高这个可以优化吗，目前没有尝试

我从dubbo中的源码中看到了在linux的系统变量user.home路径下有线程池耗尽时的线程日志，这个日志是dubbo执行拒绝策略的时候导出的线程堆栈，你可以上服务器看看。我已经解决了这个问题。

我这个日志就是那个路径的日志的一部分，我这个不是经常发生，可能是暑假人多现在基本没有，我就是想知道为什么

[steveguoshao]

我遇到的情况类似，dubbo版本2.5.10，线程池明明满了，但是却没有抛出hread pool is EXHAUSTED!, jstack dump出来的全是WAITING，dubbo默认的两百个线程全部都用上了，CPU负载也不高

[yllions]

我们也遇到这个问题，有官方同学来回答一下吗