一、业务背景#

二、服务架构#

服务使用线程池对请求进行业务处理，corePoolSize=32，maximumPoolSize=128。

三、问题描述#

服务部署到测试环境，将线上流量通过tcp-copy打到服务上后，测试反馈出现丢失消息的情况。查看服务日志，发现了

service overload discard msg

即业务线程处理缓慢造成消息堆积队列超限，后续消息被ExecutorService的Reject策略主动丢弃。

查询服务请求QPS为500/s，不算高。理论上业务处理流程没有很重很慢的操作，监控外部依赖接口的响应速度也在ms级别，所以很奇怪为什么服务的性能瓶颈这么低。

四、问题查解#

1、系统监控####

查询系统监控指标，包括CPU使用率(18%)、网卡流量、内存使用率和IO时间等，未发现异常。

查询jvm 内存使用及GC情况，未发现异常。

2、jvm 线程堆栈####

jstack pid >pid.txt打印服务进程线程栈信息：

线程堆栈信息

发现异常：

128个业务线程中有126个线程状态为java.lang.Thread.State: WAITING (on object monitor)，只有2个线程状态为正常RUNNABLE。

WAITING状态线程数

RUNNABLE状态的两个业务线程

显然大量业务线程阻塞等待在异常位置：

等待处对应的代码位置

这段代码使用了java8提供的并行流parallelStream来将消息分发给下面的listeners集合进行处理。

在开发中，我们常常通过以下方法，实现并行流执行并行任务：

myList.parallelStream.map(obj -> longRunningOperation())

但是这存在一个严重的问题：在 JVM 的后台，使用通用的 fork/join 池来完成上述功能，该池是所有并行流共享的。默认情况，fork/join 池会为每个处理器分配一个线程。假设你有一台16核的机器，这样你就只能创建16个线程。对 CPU 密集型的任务来说，这样是有意义的，因为你的机器确实只能执行16个线程。但是真实情况下，不是所有的任务都是 CPU 密集型的，这就会导致线程因IO等待浪费CPU资源，降低系统处理性能。

而测试机的CPU核数确实是2核，这就解释了上面128个业务线程中只有2个线程处于RUNNABLE状态，而其他126个业务线程都在等待的原因。->因为业务线程内部使用了parallelStream处理业务数据，所以所有业务线程内部都需要使用jvm for/join线程进行业务处理，因为只有jvm fork/join线程，所以同时只能处理两个业务线程的执行逻辑，其他业务线程排队等待执行。

五、解决方法#

1、代码修改####

将并行流parallelStream()改为stream()。

修改后的代码

2、回归验证####

重新部署测试服务器后，发现已无消息丢失报错。

观察机器负载，CPU使用率上升到40%，说明CPU资源得到了更充分的利用。

jvm YongGC频率加快到10s一次，每次GC时间为10ms，可以接受。

jstack pid > pid.txt观察现在的线程栈：

RUNNABLE状态的业务线程数

剩余WAITING状态线程

1)同时有16个业务线程处于执行状态，系统并发性大幅提升；

2)剩余处于TIMED_WAITING状态的业务线程数也降为44个，栈信息显示其在等待从线程池任务队列中取出下一个任务执行，线程池任务队列无堆积。

至此，问题处理完毕。请大家注意Java8中并行流parallelStream的使用避免才坑。