可能原因:(1) dubbo中有httpClient调用。
由于http工具默认仅支持 5 个并发,且有线程池队列,当请求量超过 5 个的时候,多余的请求会在队列中堆积。前一批http请求结束之后其他的请求才会继续执行,越到后面线程等待时间会越长。所以对应实际业务场景中dubbo线程等待的时间也会越长,当这个队列到一定数量之后,就会引起dubbo默认200个线程池被占满的情况,从而引起整个应用服务的报错。
(2) 业务代码中,有异步调用,但异步调用又使用了线程池,异步调用后又需要等待返回结果,导致dubbo调用的时间变长,很容易把dubbo线程池用光,间接导致dubbo线程占满。
(3) dubbo接口中,处理大对象,导致频繁FGC, 请求不断,但STW时间过长,也会导致dubbo线程池占满。
总结:使用dubbo框架,请求的执行时间一定要短,特别是高并发下,很容易达到dubbo默认的线程池大小(默认200)。即便调高默认值, 但也很容易导致线程太多,CPU忙碌步过来,
又间接导致执行时间变长的问题。
参考:
https://blog.csdn.net/wsmalltiger/article/details/124236055
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· DeepSeek在M芯片Mac上本地化部署
· 葡萄城 AI 搜索升级:DeepSeek 加持,客户体验更智能