情况是这样的：
A 服务要去访问 B 服务的某个接口。之前是循环访问，但是最近并发压力大了，响应变慢，就想优化成批量处理。
优化了一版本之后，上线，发现B服务机器CPU资源直接干到90+，负载直接干到10+。就赶紧回滚了，后仔细查看代码（单条处理和多条处理是一套代码，不过就加了下循环）未发现可能存在的死锁，死循环，内存泄露等问题。
后又查看了gc情况，发现ygc很频繁，6-7次/s。后优化了jvm参数，增大了新生代的大小，ygc 1-2次/s。 又进行了简单的压测。发现cpu 负载压力都可以，就上线了。上线之后没问题，但是3小时之后又出现了负载升高，cpu升高的情况。想问下还有没有排查思路哇？
现在怀疑是跟A服务建立的http连接池有关，您看哪里需要贴代码，跟我说下，谢谢大佬啦
首先你要确认B服务端的最大能力。
比如默认
B服务端最大可以开100个线程，当同时并发达到50个线程的时候，cpu已经达到了80%，那么你知道这个已经是极限了。所以，如果你希望保证健壮，就会把最大线程数控制在50以内，你要做到的是让cpu永远达不到80%。
最后，cpu升高，那么同一时刻，到底有多少线程在working，如果正比上升，那就是很合理。
情况主要是:
之前：
A服务是循环请求B服务（Get），eg：A一次处理请求B服务18次。
优化（cpu出现问题）：
A服务把循环请求的数据融合了起来成了一次（Post）去请求B服务。
按照上述，线程数应该只会减少，不会上升，http链接的数量应该也只会减少不会上升。
至于业务bug，用的同一个函数，不过只是在外层加了循环，应该不会产生bug。
那么假设：因为原来是一次一次的，中途消耗在了路上很久，A也要等发完继续发，B服务的压力没那么大。
而优化后，中途没了消耗，A也可以没阻碍的一个批次一个批次的发了，一下全在B服务了，B服务就YY了。
准备回复的时候，有点事情，后来就给搞忘了。sorry，大佬
也有想过大佬说的这个情况，但是之前一次一次的时候，阻塞应该不是严重。
而且我理解的线程数就那么多，post请求减少了生成的线程数量嘛，不应该出现阻塞的情况才对。
话说，大佬，这种情况有办法排查出来嘛？或者，如果真是这种情况的话有什么好的办法解决下嘛？
你把同时处理的线程打出来，或者做jvm的监控，都可以。
你需要把你的程序变得更透明，才能找到问题。
你的答案