关于java:记一次线上服务请求阻塞问题排查

问题

有个我的项目有一个服务节点出了问题，收到的申请始终没有返回，看日志是有收到申请，然而在接管到申请之后，没有下一步的解决（日志）了。

内存

因为该我的项目早前呈现过一次内存溢出的状况，所以第一步先看下内存状况，只应用了20%，通过jmap -heap 过程ID看到新生代和老年代都只有70%多，并且没有在快速增长。

CPU

通过top命令看到零碎CPU使用率是27.3%，服务过程是2.0%。
通过ps -mp 过程ID -o THREAD,tid,time，也没有看到服务里有哪个线程CPU特地高。

死锁查看

通过jstack 过程ID > jstack.log导出线程列表，发现没有死锁，然而线程基本上都卡在日志打印上。

"http-nio-8080-exec-199" #727 daemon prio=5 os_prio=0 tid=0x00007f766809b000 nid=0x3c0 waiting for monitor entry [0x00007f75e90c8000]   java.lang.Thread.State: BLOCKED (on object monitor)    at org.apache.logging.log4j.core.appender.OutputStreamManager.writeBytes(OutputStreamManager.java:359)    - waiting to lock <0x00000000814db020> (a org.apache.logging.log4j.core.appender.OutputStreamManager)    at org.apache.logging.log4j.core.layout.TextEncoderHelper.writeEncodedText(TextEncoderHelper.java:96)

I/O

既然线程都卡在日志打印上，那是不是I/0问题？
通过iostat -x 1 10看到%util是100%，阐明产生的I/O申请太多，I/O零碎曾经满负荷，该磁盘可能存在瓶颈。
那是不是log日志打印的太多了，进入服务器查看服务日志，发现服务开启了DEBUG日志，大量的DEBUG日志，且很多日志单行特地大，失常状况下线上是不应该关上DEBUG日志的。

解决形式

线上敞开DEBUG日志，后续继续察看是否还会复现。