<small id='I2bx'></small> <noframes id='cXOto47'>

  • <tfoot id='rXusg'></tfoot>

      <legend id='2qn90d'><style id='FqLJjr'><dir id='r5S1hg6Zf'><q id='VkULaw4ZsW'></q></dir></style></legend>
      <i id='vheqP'><tr id='mMUtDu'><dt id='7o5O'><q id='gCpQoq8v'><span id='HlXxI'><b id='nf4Y'><form id='YBUXe0zfGj'><ins id='RMFJw3y'></ins><ul id='mc3U4hCaF'></ul><sub id='oZ8h'></sub></form><legend id='N06HFqpcT'></legend><bdo id='JHfzBVeUZX'><pre id='eIK2ToN8W'><center id='QGPcej8gX'></center></pre></bdo></b><th id='XOqrWf'></th></span></q></dt></tr></i><div id='6OKWe'><tfoot id='MNDocJsLRS'></tfoot><dl id='rut0wgW'><fieldset id='qP7coS'></fieldset></dl></div>

          <bdo id='AVh5ts'></bdo><ul id='kicabNnVC'></ul>

          1. <li id='mdfY54Ov'></li>
            登陆

            做JAVA开发的同学必定遇到过的爆表问题,看这儿处理

            admin 2019-05-16 235人围观 ,发现0个评论

            布景:Java线上服务运转一周后,某个周六晚上CPU运用率忽然继续99%,Java进程处于假死状况,不呼应恳求。秉着先康复服务再排查问题的准则,在我衔接VPN选用重启大法后,CPU运用率康复正常,服务也正常呼应了,如下图一所示:

            (图一)CPU运用率图

            可是,当晚的并发量也没有比平常高出许多,为什么会忽然呈现这种CPU爆表的状况?带着这个疑问,我走上了问题排查的路途。

            首要,我查了相关的过错日志,发现毛病的时刻段内有很多的ckv恳求超时,但恳求超时并不是ckv server的问题,而是ckv client的恳求并没有宣布去。那么,为什么ckv client的恳求没有宣布去呢?日志并没有供给更多的信息给我。

            假如想学习Java工程化、高功能及分布式、浅显易懂。微服务、Spring,MyBatis,Netty源码剖析的朋友能够加我的Java高档沟通:854630135,群里有阿里大牛直播解说技能,以及Java大型互联网技能的视频免费共享给咱们。

            所以,我在Java服务上敞开了JMX,本地选用jvisualvm来调查Java进程运转时的仓库内存、线程运用状况。J气MX(Java Management Extensions,即Java办理扩展)是Java渠道上为应用程序、设备、体系等植入办理功用的结构;jvisualvm是JDK内置的功能剖析东西,坐落JDK根目录的bin文件夹下面,它能够经过JMX从Java程序获取运转时的实时数据,然后进行动态的功能剖析,如图二所示:

            (图二)jvisualvm

            经过调查Heap内存的运用状况,发现其是缓慢添加的,每隔一小段时刻被GC收回,图形呈锯齿状,好像没有什么问题;Threads也没有存在死锁的问题,线程运转杰出;在Sampler检查Thread CPU Time的时分发现,log4j的异步日志线程占用的CPU时刻是最多的。所以,开端置疑这是log4j的锅。接着,我对项目代码进行了review,发现某些接口打印了很多的无用日志,日志等级运用也不标准。最终,我对项目的日志进行了全体的整理,优化后发布上线,并继续调查。

            我本认为问题现已处理了。但是,几天做JAVA开发的同学必定遇到过的爆表问题,看这儿处理后又呈现了CPU爆表的状况,这时,我才发现自己错怪了log4j。与前次爆表的状况不同,这做JAVA开发的同学必定遇到过的爆表问题,看这儿处理次我在公司(表明很淡定),所以我机敏地保留了一台机器来做调查,其他机器做重启处理。现在,要开端我的表演了,详细如下:

            (1)登陆机器,用 top 指令检查进程资源占用状况。果然如此,Java进程把CPU撑爆了,如下图三所示:

            (图三)进程资源占用状况

            (2)Java进程把CPU都占用完了,那么详细是进程内的哪些线程占用的呢?所以,我用了 top -H -p6902 (6902是Java进程的PID)指令找出了详细的线程资源占用状况,如下图四所示:

            (图四)Java线程资源占用状况

            图四中的PID为Java线程的id,能够看到id为6904、6905、6906、6907这四个线程根本把CPU资源悉数吃完了。

            (3)现在,咱们现已拿到耗尽CPU资源的线程id了。这时,咱们就能够运用jstack来查找这些id对应的详细线程仓库信息了。jstack是JDK内置的仓库盯梢东西,坐落JDK根目录的bin文件夹下面,可用于打印的Java仓库信息。我用指令 jstack 6902 > jstack.txt (6902是Java进程的PID)打印出了Java进程的仓库信息放到jstack.txt文件了;因为仓库打印的线程的native id是十六机制的,所以,我把十进制的线程id(6904、6905、6906、6907)转化成十六进制(0x1af8、0x1af9、0x1afa、0x1afb);最终,经过 cat jstack.txt | grep -C 20 0x1af8 指令找到了详细的线程信息,如下图五所示:

            (图五)线程仓库做JAVA开发的同学必定遇到过的爆表问题,看这儿处理信息

            经过图五能够发现,把CPU占满的线程是GC的线程,Java的废物收回把CPU的资源耗尽了。

            (4)现在,咱们现已定位到是GC的问题了。那么,咱们就来看看GC的收回状况,咱们能够经过jstat来调查。jstat是JDK内置的JVM检测计算东西,坐落JDK根目录的bin文件夹下面,能够对堆内存的运用状况进行实时计算。我运用了指令 jstat -gcutil 6902 2000 10 (6902是Java进程的PID)来调查GC的运转信息,如下图六所示:

            (图六)GC运转信息

            经过图六能够知道,E(Eden区)跟O(Old区)的内存现已被耗尽了,FGC(Full GC)的次数高达6989次,FGCT(Full GC Time)的时刻高达36453秒,即均匀每次FGC的时刻为:36453/6989 ≈ 5.21秒。也便是说,Java进程都把时刻花在GC上了,所以就没有时刻来处理其他作业。

            (5)GC呈现图六的这种状况,根本能够确认是在程序中存在内存走漏的问题。那么,怎么确认是哪些代码导致的这个问题呢?这时分,咱们就能够运用jmap检查Java的内存占用信息。jmap是JDK内置的内存映射东西,坐落JD做JAVA开发的同学必定遇到过的爆表问题,看这儿处理K根目录的bin文件夹下面,可用于获取java进程的内存映射信息。经过指令 jmap -histo 6902 (6902是Java进程的PID)打印出了Java的内存占用信息,如下图七所示:

            (图七)Java内存占用信息

            由图七能够得到,占用内存资源的TOP10类([C 是指char[],String类内部运用char[]来保存数据)的称号、实例数以及占用内存大小(单位:byte),所以问题排查就变得十分简略了。最终,经过review代码确认了问题所在:

            1. 部分接口运用到了L5QOSPacket这个L5的东西类没有做单例,每次恳求接口都会生成一个新的实例,浪费了很多的内存。
            2. 代码里面用到的一个第三方供给的QcClient客户端存在内存走漏问题,代码中不恰当地new了很多的目标,并且对存储在ConcurrentHashMap的数据没有做铲除整理,然后导致数据一向累计,内存占用继续添加。

            处理以上两个问题后,Heap内存的占用维持在2.5G左右,现已没有继续增长的痕迹了,事务已正常运转。

            以上便是我排查问题的整个进程,以及在这个进程中用到的一些Java功能监测东西。除了本文提及的jvisualvm、jstack、jstat、jmap这些东西,在JDK根目录的bin文件夹下面还有其他许多十分有用的东西,例如:运用 jinfo 检查Java进程相关信息,感兴趣的童鞋能够去研讨下。

            欢迎作业一到八年的Java工程师朋友们参加Java高档沟通:854630135

            本群供给免费的学习辅导 架构材料 以及免费的回答

            不懂得问题都能够在本群提出来 之后还会有直播渠道和讲师直接沟通噢

            请关注微信公众号
            微信二维码
            不容错过
            Powered By Z-BlogPHP