慎用多线程 -- 记录线程阻塞问题

问题描述：

有一个方法会获取多个图标的点亮状态，考虑性能所以用stream并行流实现，使用forkjoin默认线程策略，前端会同时用3个主键id调3次这个接口，但测试/预发布环境大概率只有1个接口响应很快，另外2个接口一直等待最后会超时，线上则没有这个问题。

接口等待过程中如果把任意一个接口copy出来用postman调，其实响应速度也很快，不超过500ms，说明并不内部方法阻塞了

问题分析：

测试/预发布机器配置比较低，所以核心线程数和最大线程数都比较小，巧妇难为无米之炊，无论是使用自定义线程池，还是forkjoin的工作窃取模式，都依托于线程数，线程少了，一旦请求量多，就切换不过来了。3个方法同时争夺几个线程，其中某个方法拿到了，另外2个方法就阻塞了。

解决方案：

使用单线程慢慢跑。。。

待解决问题：

forkjoin和自定义线程池的默认策略都是等待，那么理论上即使某个方法先拿到先使用线程，那这个方法执行完之后应该把线程归还回去，另外两个等待的方法应该就可以拿到归还的线程了，实际效果应该是3个方法执行时间500ms,1000ms,1500ms才合理一些，结果方法1执行时间500ms，方法2和3基本都要1min左右