原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。简介在之前的OOM问题复盘之后，本周，又一Java服务出现了内存问题，这次问题不严重，只会触发堆内存占用高报警，没有触发OOM，但好在之前的复盘中总结了dump脚本，会在堆占用高时自动执行jstack与jmap，使得我们成功保留了问题现场。查看堆占用分布发现有heapdump文件后，我立马拷贝到本机，并使用MAT分析，如下：很显然，好像是什么接口分配了非常大的String对象，一个String对象约200MB，那它是哪分配的呢？查找大对象分配线程这个分配行为肯定是某个线程做的，而线程是最常见的GCRoot，因

原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。简介最近，我们系统配置了GC耗时的监控，但配置上之后，系统会偶尔出现GC耗时大于1s的报警，排查花了一些力气，故在这里分享下。发现问题我们系统分多个环境部署，出现GC长耗时的是俄罗斯环境，其它环境没有这个问题，这里比较奇怪的是，俄罗斯环境是流量最低的一个环境，而且大多数GC长耗时发生在深夜。发现报警后，我立马查看了GC日志，如下： 日志中出现了to-spaceexhausted，经过一番了解，出现这个是由于g1在做gc时，都是先复制存活对象，再回收原region，当没有空闲空间复制存活对象时，就会出现to-space

原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，转载请保留出处。简介最近，我们系统配置了GC耗时的监控，但配置上之后，系统会偶尔出现GC耗时大于1s的报警，排查花了一些力气，故在这里分享下。发现问题我们系统分多个环境部署，出现GC长耗时的是俄罗斯环境，其它环境没有这个问题，这里比较奇怪的是，俄罗斯环境是流量最低的一个环境，而且大多数GC长耗时发生在深夜。发现报警后，我立马查看了GC日志，如下： 日志中出现了to-spaceexhausted，经过一番了解，出现这个是由于g1在做gc时，都是先复制存活对象，再回收原region，当没有空闲空间复制存活对象时，就会出现to-space

原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。简介现如今，有两种常见的软件资源几乎成了Java后端程序的标配，即线程池与连接池，但这些池化资源非常的重要，一旦不够用了，就会导致程序阻塞、性能低下，所以有时我们需要看看它们的使用情况，以判断这里是否是瓶颈。查看活跃线程数在Linux上，通过top-H-p1命令，可以查看java进程的线程情况，其中1是java进程号，如下：如上，可以看到线程的名称、CPU使用率等，其中http-nio-8080-e就是Tomcat线程池中的线程，tomcat线程全名类似于http-nio-8080-exec-20，由于Lin

原创：扣钉日记（微信公众号ID：codelogs），欢迎分享，非公众号转载保留此声明。简介现如今，有两种常见的软件资源几乎成了Java后端程序的标配，即线程池与连接池，但这些池化资源非常的重要，一旦不够用了，就会导致程序阻塞、性能低下，所以有时我们需要看看它们的使用情况，以判断这里是否是瓶颈。查看活跃线程数在Linux上，通过top-H-p1命令，可以查看java进程的线程情况，其中1是java进程号，如下：如上，可以看到线程的名称、CPU使用率等，其中http-nio-8080-e就是Tomcat线程池中的线程，tomcat线程全名类似于http-nio-8080-exec-20，由于Lin