扣钉日记

本周，又一Java服务出现了内存问题，这次问题不严重，只会触发堆内存占用高报警，没有触发OOM，但好在之前的复盘中总结了dump脚本，会在堆占用高时自动执行jstack与jmap

在之前的OOM问题复盘中，我们添加了jmap脚本来自动dump内存现场，方便排查OOM问题。 但当我反复模拟OOM场景测试时，发现jmap有时可以dump成功，有时会报错。

java服务上线后，偶尔会发生内存OOM问题，但由于OOM导致服务不响应请求，健康检查多次不通过，最后部署平台kill了java进程，这导致定位这次OOM问题也变得困难起来。

突然，老哥发出一声卧槽，"我传参里的+号，到你这怎么变成了空格！"，这个声音很大，我明显的听到了，很快，我就大概Get到了他们的问题点。

这周正在写代码，突然，旁边小哥问我个问题... 小哥：我这有个接口，自己调用没有问题，但别人调用就不行，这种问题该如何排查？ 我：抓下包看看呢... 小哥：是这样使用tcpdump吗？

现如今，有两种常见的软件资源几乎成了Java后端程序的标配，即线程池与连接池，但这些池化资源非常的重要，一旦不够用了，就会导致程序阻塞、性能低下.

日常编程工作中，Java集合会经常被使用到，且经常需要对集合做一些类似过滤、排序、对象转换之类的操作。 为了简化这类操作，Java8添加了一套新的Stream API，使用方式就像写SQL一样！

上次解决了GC长耗时问题后，系统果然平稳了许多，然而，过了一段时间，我检查GC日志时，又发现了一个严重GC问题😒

最近我观察到一个现象，当服务的请求量突发的增长一下时，服务的有效QPS会下降很多，有时甚至会降到0，这种现象网上也偶有提到，但少有解释得清楚的，所以这里来分享一下问题成因及解决方案。