Labs导读

作为开发者，在日常上班中经常会碰到Java服务端程序无法照应客户端的恳求，轻则影响用户体验，重则会形成严重缺点。这种无法照应客户端的恳求就是常说的服务假死、卡住了。那么，在这种假死的面前究竟出现了什么事，本该反常照应客户端恳求的进程、线程又在做什么呢？本文带你来揭晓这一答案。

Part01、程序假死的迹象

服务端程序卡死之后，最经常出现的现象是无法照应客户端恳求，结果前往特意慢直至超时。假设是网页服务，那么用户会发现该页面会无法访问，或许不时加载不进去。

假设此时深化检查Http协定，其前往形态码普通是504（GatewayTimeout），揭示网关超时。假设该程序对应的进程还在存活在操作系统中，在扫除了网络、主机疑问后，可以以为该程序曾经假死，无法再继续提供服务。有些程序在假死后过一段期间可以自己复原，但是更多的时刻须要人工参与重启程序能力复原反常。

Part02、如何定位假死疑问

接上去咱们看一下当碰到程序假死疑问时，应该从哪些方面着手处置，如何极速定位到基本要素。

2.1罕用的工具

工欲善其事必先利其器，咱们首先来看下一些罕用的诊断疑问的工具。

2.1.1top命令

top命令是下罕用的性能剖析工具，能够实时显示系统中各个进程的资源占用状况，操作系统自带。在终端中输入top即可看到正在运转的一切进程占用的CPU、内存、运转期间等，也能够大抵通晓以后主机的运转形态。

top命令结果

以上是一张典型的top命令结果图，可以看出java进程启动占用了44.7%的内存，118.8%的CPU（多核的CPU经常使用率会超越100%），但系统1分钟的平均负载（loadaverage）只要0.92，运转较为稳固。

2.1.2jstat命令

jstat是用于监控虚构机各种运转形态信息的命令行工具，包含了对Heapsize和渣滓回收状况的监控，由JDK提供。当须要了解JVM的运转形态时它是首选工具。比如须要每秒检查一次性JVM的渣滓回收形态，可以经常使用：

jstat命令结果

上图是进程号为4417的JVM进程的内存经常使用状况，S0和S1是重生代中幸存区经常使用比例，E是伊甸园区空间经常使用比例，O是老年代空间经常使用比例；YGC是重生代渣滓回收次数，YGCT是重生代渣滓回收总期间；FGC是老年代渣滓回收次数，FGCT是老年代渣滓回收总期间，GCT是渣滓回收总期间。当出现内存不够用时，O会出现100%，并且FGC和FGCT继续参与，比拟容易别离。

2.1.3jmap命令

jmap是JDK提供的一个可以生成JVM的堆转储快照dump文件的命令行工具。除此以外，jmap命令还可以检查finalize口头队列、Java堆和方法区的详细信息，比如空间经常使用率、以后经常使用的什么渣滓回收器、分代状况等等。当出现内存疑问时，就须要jmap命令将内存堆转储成文件启动详细的剖析了。罕用的命令如下：

该命令将堆转储成名为memory.hprof的文件，后续可以经常使用堆内存剖析工具（如EclipseMemoryAnalyzer）等启动详细剖析，在此不再开展。

2.1.4jstack命令

jstack是JDK提供的一个可以生成JVM以后时辰的线程快照信息的命令行工具，可以探查在命令口头那一刻JVM中每个线程都在做什么。在实践经常使用中，可以每隔10秒钟口头一次性，延续口头几次再对比剖析，实践中的输入内多会比拟多，倡导转存到文件中繁难剖析。罕用的命令如下：

jstack命令局部结果

上图是jstack命令的局部结果，显示名为logback-8的线程此刻正在期待形态，未口头实践的义务。

2.2诊断三把斧

JVM进程假死其实就是线程不够用了，忙不上来，用以下三把斧依次实施，基本上能够笼罩90%以上场景。

2.2.1看进程

首先，经常使用top命令对主机的负载和进程的资源经常使用做一个评价。尤其关注top命令中的负载目的和进程的CPU、内存经常使用率。负载代表主机的忙碌水平，它综合了CPU、IO等目的，负载/CPU数>1代表主机十分忙碌。当系统负载高时，而每一个进程的CPU都不高时，要思考主机能否曾经过载，比如运转进程过多、IO瓶颈等。当某个进程的CPU经常使用高时，疑问大略率出在该进程中，即可对该进程启动探查。（本文只探讨JVM，故进程特指JVM进程）

2.2.2看内存

经常使用jstat命令检查JVM的内存形态。当JVM内存走漏造成堆内存无法回收、堆内存不够用从而触发频繁的FullGC时，JVM会进度程序的口头启动片面的渣滓回收（stoptheworld），此时程序将无法照应恳求，GC线程会占用少量的CPU期间。当这种状况出现时，会出现进程CPU经常使用率很高，凑近系统极限。堆内存中老年代空间经常使用比例凑近或到达100%，FGC、FGCT在继续地回升（反常状况下FullGC几小时甚至几天赋口头一次性）。

当判别为进程因内存疑问而不时在FullGC时，可以经常使用jmap命令将内存dump上去进后退一步的剖析，查找内存走漏的对象，进而进一步找到内存走漏点。此外，值得留意的一点是假设堆内存自身设得很小，而程序须要的内存又很多，JVM会尝试去回收内存，也会出现频繁的FullGC而造成CPU经常使用率升高的状况。这就须要详细疑问详细剖析了。

2.2.3看线程

经常使用jstack命令检查线程形态。当操作系统、堆内存都无清楚意外状况下，须要进一步探查每一个线程都在做什么。线程无法处置更多义务，要么是线程都很忙（单核CPU100%），要么是都在期待（CPU经常使用率不高），极少数是处于死锁形态，而这些都可以从jstack的命令结果中看进去。

jstack会显示每个线程以后所处的程序栈。假设多个线程处在同一个程序栈，那么要惹起高度留意，可以经过延续几个距离10秒左右的jstack结果检查该线程能否不时处于同一位置，假设是那么大略率是卡在了这里。假设是死循环，那么CPU经常使用率会很高，假设是期待IO，那么CPU经常使用率会很低。经过卡住的程序栈，可以较容易定位到代码行并进后退一步的剖析了。

Part03、案例实战

了解完基本的通经常识，上方经过实践上班中碰到的案例来经常使用三把斧启动剖析。

3.1案例一：IO期待

系统体现 ：界面无照应，恳求API也无照应。

看进程 ：top命令显示系统负载很低，进程CPU、内存经常使用也无心外。

看内存 ：jstat命令显示堆内存体现反常：

jstat显示堆内存形态反常

看线程 ：jstack命令显示绝大局部线程都卡在同一个中央：

出现io期待的线程

经过进一步审核AbstractProvinceServiceImpl.sendPost方法，发现是经常使用java原生的HttpUrlConnection来成功Http恳求的方法，而该方法未设置超时期间，假设被调用方未前往会不时期待。

有缺陷的代码

至此，疑问要素查明：因代码缺陷，在动员http恳求时未设置超时期间，而恰恰此时被调用方系统缺点，无法及时前往，从而造成线程都卡在这里期待IO，无更多的线程来照应其余恳求了。

3.2案例二：死循环

系统体现 ：系统照应很慢，api恳求有必定的失误率。

看进程 ：top命令显示系统负载较高（1核CPU），进程CPU到达190%，系统过载。

负载较高，进程CPU经常使用率较高

看内存 ：jstat命令显示堆内存体现反常，无清楚的内存疑问。

看线程 ：屡次距离口头jstack命令，发现一局部进程不时卡在同一个中央：

出现死循环的线程

经过检查关系代码发现这里有个死循环，当变量cur不时不为null时，程序无法跳出循环。经过更进一步的剖析，最终找数据库中的一条数据其CateParentId是自己，从而触发这个死循环的bug。

...while(Objects.nonNull(cur)){allCateName.insert(0,"/");allCateName.insert(0,cur.getCateName());cur=goodsCatePOMap.get(cur.getCateParentId());}...

Part04、总结

关于Java服务端假死，可以经过本文引见的三把斧，应用一些罕用工具来对程序外部的运转形态启动剖析。把握这个方法后，基本上可以定位到上班中碰到的90%以上的java程序假死疑问。下表是对或许的假死要素做一个繁难的演绎总结：

关于java多线程的疑问，为何单步没问题的程序去除断点后运行就会有问题？

用测试类跑的吧？测试类的主线程结束之后，容器就直接关掉了，你开的那些线程已经没有运行环境了，所以你让主线程等下在结束，容器保持开启状态，其他线程才能执行完；这个问题在程序正常启动的时候是不存在的。

为什么服务器的宕机一般都发生在凌晨使用率最低的时候？

计科专业从事嵌入式软件开发多年，最近因为公司需要搞后台研发，经常选择升级的时机放在凌晨，而且大型的数据处理也是放在这个时间段内，经常发生的服务器宕机也是在这个时段。 都是在用户使用少的时候开始折腾，折腾的次数多也就容易出现服务器问题。 由于做的是物联网设备，在工作中遇到的宕机主要有这么几种情况，对大量数据的操作导致CPU占比在一段时间内骤增从而导致数据接收模块出问题，导致系统监控出现问题，很多设备信息检测不到了。 对数据库的操作太频繁导致效率的下降，也是影响系统性能很重要的一部分，其实服务器也是普通电脑的构成，主要的资源是CPU和内存，这两个因素无论是哪种都有可能导致系统的崩盘，如果是CPU被占满了，系统的反应会变得异常缓慢，时间长了可能还会慢慢缓过劲来，内存如果占满了那么会导致系统的崩溃，直接运行不下去了，其实宕机核心点不会跑出这两种因素。 现在就常见的服务器宕机问题做个归纳总结： 1.磁盘空间被占满，现在程序员运行的时候都习惯于带上log打印，如果时间长了加上没有清理的机制早晚会出问题，这个错误在平时运行过程中经常出现，如果使用的云计算服务器通常在系统崩盘之前都会发个短信，通知你的系统处于崩溃的边缘。 2.并发性能问题，如果多个人同时操作一个数据库或者数据块，会导致系统假死状态，这种属于争抢CPU资源问题，可以通过增加硬件配置以及优化软件代码的效率去解决，数据量如何足够大就可以考虑分布式的管理 3.数据受损或者被破坏导致系统崩盘，所以常见的做法是都会配置备份盘，出现问题抓紧拿到备份盘来顶上，现在公司使用的是阿里云的服务器，稳定性相比之前好太多了，中间换过电信云，腾讯云虽然价格低点，最后受不了直接换成阿里云，再也不想换回去了，数据的稳定性永远是第一位的。 4，一些没有必要的误操作，很多时候是因为程序员或者运维人员的误操作大致服务器大面积的宕机，这种事件在很多云服务提供商身上都发生过，根本层面还是管理问题。 后台管理的任何细节都有可能服务器宕机查找问题的几个线索： 1.看看服务器是不是存在内存泄漏问题，有些时候重启机器开始还能正常运行弄了一段时间之后就会变得非常缓慢，十有八九都是内存的问题 2.是否有黑客入侵造成，有些非常关键重要的数据也是黑客最感兴趣的，一般来讲这种概率不是很高 3.是不是数据库死锁导致的，访问量过大导致，连接数过多造成的。 服务器宕机一旦发生就会引起用户的无数的投诉，无论在什么情况下稳定永远是第一位，现在大的功能升级除非已经百分百验证成功，否则引起的后果不堪设想。 希望能帮到你。 之前我们单位夜晚有一台设备down了，这台设备做的堆叠，而不是备份，所有下联线路全部连接在主设备上。 结果当晚凌晨，主设备的电源模块损坏了！这...你能看出规律吗？我也想知道为什么它偏偏凌晨损坏了！ 所以说，偶然性事件，不能说大部分！ 但是夜间割接倒是正常，选择在用户最少的时候做可能影响业务的必要事情是常识。 虽说在凌晨的时候，使用系统的用户非常少，但是服务器在这个时候要做的工作可能一点儿也没有少：再说一个很久以前看到的，同行们分享的服务器宕机的经历，有些经历非常之神奇，大家就当段子看吧（为了方便，我就按照第一人称来讲述）。 我们服务的甲方是一家医院，机房就在医院的楼中，最近机房的服务器经常性的发生宕机，公司的工程师去了几次也没有发现问题；后来公司被折腾的没办法了，决定让一个工程师晚上住在机房，看看半夜机房中究竟发生了什么事儿，想着就算找不到原因，也能在服务器宕机后第一时间重启。 后来发现原因，到了凌晨三四点的时候，机房门打开了，进来一个值夜班的小护士，看了一眼说：“又没有人，开着空调不浪费电么？”然后就把机房的空调关掉了，然后气温上升...我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。 偶发性的，可以能是你浅意识的，因为这种问题印像最深刻，可能认为比较多，通过做记录去试下。 宕机一般分5种情况：1、程序上出了问题导致程序崩溃。 2、cpu\\Gpu 、内存占满了。 3、硬盘空间满了 4、数据库表空间满了 5、机房温度过高 以上是个人在运维过程中所遇到的问题，做的总结性回答 这里需要说明一下，服务器宕机是什么意思呢？ 我们日常说的“宕机”中的“宕”其实指的是英文“down”，宕机表示当前服务器或服务无响应或者不在线状态。 服务器的宕机可分为人为控制的宕机、不可控的宕机。 这两者有什么区别呢，下面来具体说明一下： 1、人为可控的宕机行为 服务器长时间的运行可能会带来一些（非致命性）问题，又或者我们需要对服务器进行软/硬件的升级维护时，可能需要停机或者重启操作。 这种情况下的宕机是可控的，在我们的计划之内。 2、不可控宕机行为 这种因素就很多了，比如说 服务器突然蓝屏、服务异常崩溃、突然断电断网了 ，这时候服务(器)就无法正常提供服务，这些都是不可控因素导致的。 而 在我们的日常运维工作中，计划性的宕机维护一般都选择在半夜 来做这些事，为什么呢，原因主要有这几点：1、 减少对用户的影响 凌晨大家基本上都休息了，用户量较白天来说小得多，所以选择在此时进行系统及硬件的维护导致的宕机对用户的影响较小，就算有影响也只是影响小部分用户。 2、 有足够的时间来处理故障 在凌晨进行维护，就算有问题，技术人员也有足够的时间（比如说：00~05点）去处理故障。 如果换成在日间维护，服务(器)宕机1小时以上投诉单全都过来了，压力很大的。 服务器宕机是指服务器因为一些原因导致服务器无法正常运行，造成网络断开，无法正常使用网络。 服务器宕机一般都发生在凌晨，为什么会出现这种情况呢？ 像我们公司是从事 科技 互联网设备生产的，为了不影响正常生产，系统升级的时候一般都是在凌晨，而且很多的数据处理也放在这个时候，服务器在这个时候也容易出现问题，具体分析有以下几种原因：1. 系统在升级或处理大的数据时，硬盘空间被占满，如果没有人能及时清理磁盘空间，服务器就会出现卡顿的问题造成宕机。 2.如果是多台设备同时在操作，使用这一个数据库，会引起系统假死的现象，这个是属于抢占CPU的资源造成的，会导致服务器不堪自负，网站访问量猛增，程序中毒遭到很多的应用都在消耗服务器，最终死机无法响应。 3.由于凌晨维护人员减少，会出现断电，温度过高等等环境因素的影响，使服务器死机等等，不过这种情况是很少见的，因为现在机房都有发电机备用避免停电造成的数据丢失，温度也是采用的恒温系统。 4.有的企业为了节省服务器的费用，会租用较低配置的服务器来从事很多的工作，使服务器超负荷运转，结果是可以预料得到的，宕机就会经常发生。 5.服务器宕机一般和内存有很大的关系，有些服务器运行了一段时间后速度就变慢了，基本上就是内存出现问题，要检查一下内存是否存在泄漏的问题。 服务器宕机会出现一系列的问题，造成的损失也是无法估量的，只有平时定期做好维护，在凌晨的时候也要注意掌握使用状况才能避免宕机，无论在任何时候，服务器的稳定运转才是最重要的。 服务器应用软件在运行过程中状态很稳定，一般不会发生问题。 宕机发生在凌晨概率高的原因是：一是功能升级、硬件更换多在凌晨，导致问题发生概率高；二是批量执行多在凌晨，瞬间资源消耗很大，数据问题、硬件资源问题、甚至处理逻辑问题都容易导致宕机。 另外，如果是联机交易出了问题，很容易被发现，不会让系统宕机。 原理其实很简单：这就如同我们白天忙碌着很多事物性的工作，就如同搬运工一样，不停的搬运物品入库，只有在物品都搬运完了的时候，我们才能开始整理这些物品，整理仓库，。 其二，服务器在白天的时候，其实都在实时处理数据的“搬运工”状态，只有在实时性数据处理工作（搬运工作）完成以后，才有机会或才能腾出手来去做数据的归纳和整理。 所以，服务器的宕机时间，通常会发生在使用率最低的时间段。 仅此。 正常跑稳的业务，一般很难因为正常业务操作造成服务器宕机的。 服务器资源问题大部分情况下是可预测，可控制的。 最容易造成宕机的事情，反而是开发/运维的不当操作造成的。 比如更换服务器硬件，升级/安转os程序包，发布新代码，批量更新数据等等，这些事一般都是半夜业务量小的时候做。 因为凌晨是最困得时候，服务器一打盹就宕机了。