Java系统宕机解决方法论

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Java系统宕机解决方法论，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6792字，纯文字阅读大概需要10分钟。

内容图文

1 宕机概要

1.1 定义

一般我们认为向服务器的请求都没有响应或者响应非常缓慢的情况都称为宕机.

表面的前端崩溃并不是宕机

1.2 分类

• 进程闪退
  • 内部崩溃
  • 外部终止
• 线程锁死或者无限等待
• 内存溢出

下面分别进行详解

2 进程闪退

2.1 内部崩溃

JVM 发生内部崩溃，那么必然会生成"hs_err_pid"开头的文件,下面讲一种常见情况:

• 无法申请内存，显示commit_memory错误类似如下所示内容
  
  一般是因为 Xmx 设置过大，超过系统可用内存，导致 JVM 申请内存失败，比如服务器总内存32G ，同时运行多个程序,程序 A 配了20G的Xmx,其他程序也配了20G Xmx ，Linux的交换空间也没有设置，这时候如果其他程序用满20G的内存那么服务的可用内存必然低于12G，这时如果Tomcat需要大于12G的内存就很容易发生该错误，直接宕机，解决方案：
  • 减少Xmx值使得所有的综合不超过服务器物理内存
  • 调整 Xms=Xmx
  • 服务器不要运行其他不必要的东西
  • 配置一部分swap空间（虚拟内存）

2.2 外部终止

如果找不到"hs_err_pid"开头的文件那么，这个进程的闪退必然是被从外部终止的。

2.2.1 OOMKiller

java长期内存占用过高，系统需要内存使用的时候没有内存，Linux的oomkiller机制会干掉最低优先级的内存

检查 /var/logs/message ， /var/logs/dmesg或者对应日期文件，看看有没有类似下面的内容，日志有时间可以判断

oomKiller的具体解决方案可以自行检索，不外乎 1：关闭oomkiller（不推荐），2、其他方案同内部崩溃无法申请内存的方案

2.2.2 SSH用户注销 - 最常见

检查/var/log/auth.log，/var/log/secure或者对应日期的文件，检查宕机的时间点有没有

时间吻合，那么宕机原因即可确认。

解决方案，使用nohup命令在后台运行启动程序，检查ssh注销原因

2.2.3 其他人为因素

不是很好判断，需要给shell加上操作记录

3 线程锁死/无限等待

表现为系统无法访问时，当前cpu占用非常低

使用 jstack命令输出线程堆栈即可

jstack pid >> 1.txt

or

jstack -F pid >> 1.txt

都行,或者用jprofiler工具看堆栈，或者其他任何可以拿到堆栈的工具都可以， java的堆栈就是java方法调用的路径，可以定位一些简单的问题

4 内存溢出(重点)

表现为CPU全部占满，内存达到配置Xmx最大值

4.1 为什么CPU会占满

并不是 CPU 不够用，而是涉及到JVM的GC 机制，大部分情况来说CPU都是过剩的

JVM 使用GC的方法来回收没有被引用的内存块，在当前的回收机制中，回收器是并发进行的，回收的线程个数有一个公式：

当CPU核心数

• 小于8
  1个核心对应一个gc线程
• 大于8
  gc的线程数= 8 + ((N - 8) * 5/8)

N代表核心的数量，这是默认的gc线程创建公式

threads = N <= 8 ? N : (8 + ((N - 8) * 5/8))

当然也可以通过参数 -XX:ParallelCMSThreads=20 来配置 GC 线程数，就不会使用默认的设置，默认情况下不要调整，因为调了也没什么卵用，最多在宕机的时候cpu占用按照你设定的值来。

当发生内存溢出的时候，或者快要内存溢出的时候，不一定是内存溢出，JVM 发现内存不够了，就会 GC，所有线程开始工作，暂停 JVM 运行，开始回收，如果回收到内存了，ok，jvm可以正确继续执行，

这也就是为什么有时候配置内存溢出的参数没有自动生成dump的原因，因为他能运行，但是比较慢，所以没有OOM，就不会生成dump，

如果没有回收到什么内存，gc会循环持续执行，这就导致了cpu全部占满的现象，所以说内存溢出的时候，一定伴随cpu占满（按照设置或者公式计算的线程量）

4.2 JVM内存分配机制

在说说JVM怎么分配内存的，大家都知道给客户配置Xmx参数和xms参数，Xmx代表的是最大堆内存，xms代表的是最小堆内存，至于permsize就和这些都没有关系，不能算在内存溢出，遇到抛错outofmemory permsize什么的调大就行了

permsize是一个被jvm也抛弃的参数只存在1.7之前的jdk中，是用来保存java的class等内容的存储空间，1.8被metaspace替代

这个内存怎么不回收的啊，一问都是在任务管理器看的!这个地方是看不到内存回收的，或者说他也会回收，但是可能要等个好几天才会回收一次，可以忽略这种机制的存在

形而上学

WC 论

把内存比喻成茅坑，操作系统64g内存就是一共64个茅坑，那么JVM的内存回收相当于茅坑调度系统，每个gc线程相当于调度系统派出去的茅坑检查员，给jvm设置了 Xms=2g， Xmx=32g，那么程序启动，jvm直接占了两个茅坑，任务管理器看到内存占用2g，即使没人上厕所，JVM也不会把坑还给操作系统

假设一个人上厕所10秒，一开始的时候 20秒有一个人来上厕所，那么 jvm通过茅坑检查员发现哎两个坑总有一个是空的，维持茅坑数量不变，内存的占用一直是2g，过了些时候，来的人开始增多了，变成5秒有一个人来上厕所，茅坑检查员向JVM汇报有人开始有排队了，两个坑位很紧张，不行要多弄几个坑才行，于是，jvm向系统又申请了两个坑，任务管理器可以看到内存占用变成了4个G，这时候又突然发生压力增大，变成了1秒来一个人，4个坑肯定不够啊，于是jvm又把内存扩容到10-11g，现在够用了，任务管理器会看到内存一直维持在10-11g，终于大家都上完厕所了，没人排队了，茅坑都空出来了，但是，jvm是个霸道总裁，被他占的东西，除非死不然不会吐出来的，所以任务管理器里面看到内存还是10-11g不会降低，除非jvm死了，实际没有任何内存占用（所以不要再说内存不回收的问题，这个内存的回收不回收和宕机是没有直接关系的）

如果这时候突然一下子来了很多很多的人，比如一下子来了64个人要上厕所，这时候会怎样了，JVM把他的所有的茅坑检查员都派出去检查啊，然后发现完蛋了茅坑不够用啊，申请到32个都不够用啊，于是jvm的特派茅坑检查员就一个坑一个坑的拍，一个坑一个坑的催，结果呢，检查员在催，大家就拉不出来了，上厕所的时间无限期延长，外面的人要进去，里面的人出不来，BOOM，厕所就不响应了，后面来的人都拉裤子了。

怎么解决问题呢?

• 换个茅坑管理员，更好的调度茅坑检查员和分配茅坑，这就有了G1回收器 ，茅坑越多效果越好，目前JDK情况内存大于10G的情况G1的效果好于CMS，低于10G的情况下不如CMS
• 从源头控制人员，不要一下子来这么多人（申请内存），也就是常见的不要让模板查大量数据或者发生笛卡儿积的行为

而上面讲的线程锁死的情况要做类比的话，就是32个坑呗32个人占了，还死活不肯出来，导致后面排队的人失去响应了。

没有味道的比喻

解释一下java的面向对象和对象引用

一栋大楼 10层一共1000个工位 （类比物理内存）
包给一个二房东 中介公司Z （jvm）
中介公司和大楼物业谈好了 弹性缴费
租多少出去收多少钱
Z公司先一下子租了300个位置 （类比Xms）省钱

Z公司和物业谈好最多租600个位置（类比Xmx）

Z公司找到了公司A(200人)来这里 就占用了200个工位 （类比报表一次查询）
公司A是一个大的对象，每个人就是 类比最小的单元格，每个小团队也是一个对象，个人被小团队引用，小团队又被更上级的比如产品，比如大技术支持大团队引用，大团队又被公司引用，最终公司这个大对象
占用了200工位，类比下来200个工位内存不释放的根就是这个公司在这儿上班
这时候公司A倒闭了，200个工位就空出来了(内存释放)
内存溢出宕机是什么情况呢？
找Z公司租工位的公司 总工位超过了600，总不能坐大腿上上班啊，于是物业不会给Z工位的，合同写的好好的，Z公司不满足客户需求，运作不起来破产倒闭

还有经常遇到的申请内存失败的崩溃是什么情况呢?

物业是个滑头，不止找了Z公司一家中介，还有Y公司也是做中介的，(类比两个JVM)

并且都承诺Z和Y公司都是最多可以租600个位置

初始都租的300个位置，大家相处融洽

随着公司不停入住，这时候矛盾就出现了

Y公司效益比较好，先找了公司，已经占了600个位置了

这时候Z公司的效益也上来了，也要增加工位 （类比申请内存）

这时候物业根本没有位置能给他。

于是Z公司运转不下去，破产倒闭

5 总结

宕机分析的目的就是要找到占用内存的东西，把他找出来，找出他的原因，然后把它改掉。JVM的内存对象分配相当于一颗树，所有的对象都被层层引用，直到GCRoot根节点，如果没有根节点的引用，这个对象是完全可以直接释放掉的，大部分也是因为gcRoot存在的对象过多导致的宕机，当然也不排除可以使用已经回收的对象来分析，由于生成dump的时间不精确，可能他生成的时候 ，对应的大组件已经回收了，但是jvm缓过来还需要一些时间，所以还是处于大量gc的状态，这时候只能通过对于引用的检索找到最多的引用对象来进行分析

• 点赞
• 收藏
• 分享
• • 文章举报

内容总结

以上是互联网集市为您收集整理的Java系统宕机解决方法论全部内容，希望文章能够帮你解决Java系统宕机解决方法论所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端