W

你把同时处理的线程打出来，或者做jvm的监控，都可以。
你需要把你的程序变得更透明，才能找到问题。

准备回复的时候，有点事情，后来就给搞忘了。sorry，大佬
也有想过大佬说的这个情况，但是之前一次一次的时候，阻塞应该不是严重。
而且我理解的线程数就那么多，post请求减少了生成的线程数量嘛，不应该出现阻塞的情况才对。
话说，大佬，这种情况有办法排查出来嘛？或者，如果真是这种情况的话有什么好的办法解决下嘛？

那么假设：因为原来是一次一次的，中途消耗在了路上很久，A也要等发完继续发，B服务的压力没那么大。
而优化后，中途没了消耗，A也可以没阻碍的一个批次一个批次的发了，一下全在B服务了，B服务就YY了。

情况主要是:
之前：
A服务是循环请求B服务（Get），eg：A一次处理请求B服务18次。
优化（cpu出现问题）：
A服务把循环请求的数据融合了起来成了一次（Post）去请求B服务。
按照上述，线程数应该只会减少，不会上升，http链接的数量应该也只会减少不会上升。
至于业务bug，用的同一个函数，不过只是在外层加了循环，应该不会产生bug。

首先你要确认B服务端的最大能力。

比如默认B服务端最大可以开100个线程，当同时并发达到50个线程的时候，cpu已经达到了80%，那么你知道这个已经是极限了。

所以，如果你希望保证健壮，就会把最大线程数控制在50以内，你要做到的是让cpu永远达不到80%。

最后，cpu升高，那么同一时刻，到底有多少线程在working，如果正比上升，那就是很合理。

ps：业务bug导致的cpu飙升另说

首先，你这个客户端版本太老了，已经弃用很久了，不排除版本兼容性问题。

参考新版的消费者方式：kafka消费者Java客户端
或者我之前写的例子：kafka客户端 - java

其次，多线程消费导致的，这块非常容易出问题，线程池必须是阻塞式的，就是你多线程池子虽然设置的上限是5个，但是其实你可以无限往里面丢（比如默认有1万的队列），但是在里面排队，真正处理的是5个，也会导致这个问题。

再次感谢大佬回答，
1、我也担心客户端版本的影响，所以贴出了版本信息，有没有办法能确定客户端的版本是否有影响哇。
2、多线程消费在写这块代码的时候，考虑到了无线往里面丢的情况，但是我认为这里的代码是不会发生的。因为处理业务逻辑之前是同步分批次拿五条数据，一块丢进去，多线程处理完毕再出来，循环取后五个（外层是同步的，同步取数据赛给业务逻辑多线程处理）。对于整体的处理速度确实有提升，而且跑了差不多一个多月了，并未发现数据上的异常（应该是可行的）。

再次感谢大佬回答，
1、我也担心客户端版本的影响，所以贴出了版本信息，有没有办法能确定客户端的版本是否有影响哇。
2、多线程消费在写这块代码的时候，考虑到了无线往里面丢的情况，但是我认为这里的代码是不会发生的。因为处理业务逻辑之前是同步分批次拿五条数据，一块丢进去，多线程处理完毕再出来，循环取后五个（外层是同步的，同步取数据赛给业务逻辑多线程处理）。对于整体的处理速度确实有提升，而且跑了差不多一个多月了，并未发现数据上的异常（应该是可行的）。