一、业务背景#
二、服务架构#
服务使用线程池对请求进行业务处理，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。
显然大量业务线程阻塞等待在异常位置：
这段代码使用了java8提供的并行流parallelStream来将消息分发给下面的listeners集合进行处理。
查询资料（可参看文章 http://www.cnblogs.com/gaobig/p/4874400.html ）找到原因：
在开发中，我们常常通过以下方法，实现并行流执行并行任务：
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观察现在的线程栈：
1）同时有16个业务线程处于执行状态，系统并发性大幅提升；
2）剩余处于TIMED_WAITING状态的业务线程数也降为44个，栈信息显示其在等待从线程池任务队列中取出下一个任务执行，线程池任务队列无堆积。
至此，问题处理完毕。请大家注意Java8中并行流parallelStream的使用避免才坑。
