起源：zhenbianshu.github.io/
前些日子小组内安顿值班，轮流看顾咱们的服务，次要做一些报警邮件解决、Bug 排查、经营 issue 解决的事。工作日还好，无论干什么都要下班的，若是轮到周末，那这一天算是毁了。
不晓得是公司网络广了就这样还是网络运维组不给力，网络总有问题，不是这边交换机脱网了就是那边路由器坏了，还偶发地各种超时，而咱们灵活地服务探测服务总能精确地抓住偶现的小问题，给美妙的工作加点料。好几次值班组的小伙伴们一起吐槽，磋商着怎么避过服务保活机制，偷偷停了探测服务而不让人发现（尽管也并不敢）。
前些天我就在周末解决了一次探测服务的锅。
问题
网络问题？
早晨七点多开始，我就开始不停地收到报警邮件，邮件显示探测的几个接口有超时状况。少数执行栈都在：
java.io.BufferedReader.readLine(BufferedReader.java:371)java.io.BufferedReader.readLine(BufferReader.java:389)java_io_BufferedReader$readLine.call(Unknown Source)com.domain.detect.http.HttpClient.getResponse(HttpClient.groovy:122)com.domain.detect.http.HttpClient.this$2$getResponse(HttpClient.groovy)这个线程栈的报错我见得多了，咱们设置的 HTTP DNS 超时是 1s， connect 超时是 2s， read 超时是 3s，这种报错都是探测服务失常发送了 HTTP 申请，服务器也在收到申请失常解决后失常响应了，但数据包在网络层层转发中失落了，所以申请线程的执行栈会停留在获取接口响应的中央。这种状况的典型特色就是能在服务器上查找到对应的日志记录。而且日志会显示服务器响应齐全失常。与它绝对的还有线程栈停留在 Socket connect 处的，这是在建连时就失败了，服务端齐全无感知。
我留神到其中一个接口报错更频繁一些，这个接口须要上传一个 4M 的文件到服务器，而后通过一连串的业务逻辑解决，再返回 2M 的文本数据，而其余的接口则是简略的业务逻辑，我猜想可能是须要上传下载的数据太多，所以超时导致丢包的概率也更大吧。
依据这个猜测，群登上服务器，应用申请的 request_id 在近期服务日志中搜寻一下，果不其然，就是网络丢包问题导致的接口超时了。
当然这样 leader 是不会称心的，这个论断还得有人接锅才行。于是连忙分割运维和网络组，向他们确认一下过后的网络状态。网络组同学回复说是咱们探测服务所在机房的交换机老旧，存在未知的转发瓶颈，正在优化，这让我更释怀了，于是在部门群里简略交待一下，算是实现工作。
问题暴发
本认为这次值班就起这么一个小波浪，后果在早晨八点多，各种接口的报警邮件一拥而上，打得筹备拾掇货色过周日单休的我措手不及。
这次简直所有的接口都在超时，而咱们那个大量网络 I/O 的接口则是每次探测必超时，难道是整个机房故障了么。
我再次通过服务器和监控看到各个接口的指标都很失常，本人测试了下接口也齐全 OK，既然不影响线上服务，我筹备先通过探测服务的接口把探测工作停掉再缓缓排查。
后果给暂停探测工作的接口发申请良久也没有响应，这时候我才晓得没这么简略。
解决
内存透露
于是赶快登陆探测服务器，首先是 top free df 三连，后果还真发现了些异样。
咱们的探测过程 CPU 占用率特地高，达到了 900%。另外，JVM 系列面试题和答案全副整顿好了，微信搜寻Java技术栈，在后盾发送：面试，能够在线浏览。
咱们的 Java 过程，并不做大量 CPU 运算，失常状况下，CPU 应该在 100~200% 之间，呈现这种 CPU 飙升的状况，要么走到了死循环，要么就是在做大量的 GC。
应用 jstat -gc pid [interval] 命令查看了 java 过程的 GC 状态，果然，FULL GC 达到了每秒一次。
这么多的 FULL GC，应该是内存透露没跑了，于是 应用 jstack pid > jstack.log 保留了线程栈的现场，应用 jmap -dump:format=b,file=heap.log pid 保留了堆现场，而后重启了探测服务，报警邮件终于进行了。
jstat
jstat 是一个十分弱小的 JVM 监控工具，个别用法是： jstat [-options] pid interval
它反对的查看项有：
- -class 查看类加载信息
- -compile 编译统计信息
- -gc 垃圾回收信息
- -gcXXX 各区域 GC 的详细信息 如 -gcold
应用它，对定位 JVM 的内存问题很有帮忙。
排查
问题尽管解决了，但为了避免它再次发生，还是要把本源揪出来。
剖析栈
栈的剖析很简略，看一下线程数是不是过多，少数栈都在干嘛。
> grep 'java.lang.Thread.State' jstack.log | wc -l> 464才四百多线程，并无异样。
> grep -A 1 'java.lang.Thread.State' jstack.log | grep -v 'java.lang.Thread.State' | sort | uniq -c |sort -n 10 at java.lang.Class.forName0(Native Method) 10 at java.lang.Object.wait(Native Method) 16 at java.lang.ClassLoader.loadClass(ClassLoader.java:404) 44 at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method) 344 at sun.misc.Unsafe.park(Native Method)线程状态如同也无异样，接下来剖析堆文件。
下载堆 dump 文件
堆文件都是一些二进制数据，在命令行查看十分麻烦，Java 为咱们提供的工具都是可视化的，Linux 服务器上又没法查看，那么首先要把文件下载到本地。
因为咱们设置的堆内存为 4G，所以 dump 进去的堆文件也很大，下载它的确十分麻烦，不过咱们能够先对它进行一次压缩。
gzip 是个性能很弱小的压缩命令，特地是咱们能够设置 -1 ~ -9 来指定它的压缩级别，数据越大压缩比率越大，耗时也就越长，举荐应用 -6~7， -9 切实是太慢了，且收益不大，有这个压缩的工夫，多进去的文件也下载好了。
应用 MAT 剖析 jvm heap
MAT 是剖析 Java 堆内存的利器，应用它关上咱们的堆文件（将文件后缀改为 .hprof）, 它会提醒咱们要剖析的品种，对于这次剖析，果决抉择 memory leak suspect。
从下面的饼图中能够看出，绝大多数堆内存都被同一个内存占用了，再查看堆内存详情，向下层追溯，很快就发现了罪魁祸首。
剖析代码
找到内存透露的对象了，在我的项目里全局搜寻对象名，它是一个 Bean 对象，而后定位到它的一个类型为 Map 的属性。
这个 Map 依据类型用 ArrayList 存储了每次探测接口响应的后果，每次探测完都塞到 ArrayList 里去剖析，因为 Bean 对象不会被回收，这个属性又没有革除逻辑，所以在服务十来天没有上线重启的状况下，这个 Map 越来越大，直至将内存占满。
内存满了之后，无奈再给 HTTP 响应后果分配内存了，所以始终卡在 readLine 那。而咱们那个大量 I/O 的接口报警次数特地多，预计跟响应太大须要更多内存无关。
给代码 owner 提了 PR，问题圆满解决。
小结
其实还是要检查一下本人的，一开始报警邮件里还有这样的线程栈：
groovy.json.internal.JsonParserCharArray.decodeValueInternal(JsonParserCharArray.java:166)groovy.json.internal.JsonParserCharArray.decodeJsonObject(JsonParserCharArray.java:132)groovy.json.internal.JsonParserCharArray.decodeValueInternal(JsonParserCharArray.java:186)groovy.json.internal.JsonParserCharArray.decodeJsonObject(JsonParserCharArray.java:132)groovy.json.internal.JsonParserCharArray.decodeValueInternal(JsonParserCharArray.java:186)看到这种报错线程栈却没有细想，要晓得 TCP 是能保障音讯完整性的，况且音讯没有接管完也不会把值赋给变量，这种很显著的是外部谬误，如果注意后细查是能提前查出问题所在的，查问题真是差了哪一环都不行啊。
近期热文举荐：
1.1,000+ 道 Java面试题及答案整顿(2022最新版)
2.劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4.别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞+转发哦！