编程知识 cdmana.com

解析Java横死之谜,气定神闲看花开花落

http://xjjdog.cn 对200+原创文章进行了细致的分类,阅读更流畅,欢迎收藏。

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。任何不保留此声明的转载都是抄袭。

Java进程突然不见了,日志里并没有任何它们的信息,它们就那么凭空蒸发了。日志、OOM的一些配置参数,根本就不顶用。

不要惊慌。进程没有灵魂。一个restart,会让这些程序活蹦乱跳again。

问题是那些restart也无法解决的问题,还有默默在背后运作的墨菲定律。

是谁杀死了心爱的Java进程?

不要太绝情,在死之前,起码要让进程发表一点遗言吧。本小篇将分析几种常见的Java进程消失之谜,让你气定神闲看花开花落。

它们有可能:

  • 被操作系统审判了
  • 执行了上帝函数,被队友埋坑了
  • 使用了错误的启动方式
  • 日志系统配置错误

1. 被操作系统审判了

以下问题已经不止一个小伙伴遇到了:我的java进程没了,什么都没留下,直接蒸发不见了

why?是因为太多情,对象太多了么?

这是趣味性和技巧性非常突出的一个问题。

执行dmesg命令,大概率会看到你的进程崩溃信息躺尸在那里。

为了能看到发生的时间,我们习惯性加上参数T

dmesg -T

明显是操作系统看你的进程不顺眼,给Kill了。

这个现象,和Linux的内存管理有关。

由于Linux系统采用的是虚拟内存分配方式,JVM的代码的使用都会消耗内存,但是申请出来的内存,只要没真正access过,是不算的,因为没有真正为之分配物理页面。

随着使用内存越用越多。第一层防护墙就是SWAP;当SWAP也用的差不多了,会尝试释放cache;当这两者资源都耗尽,杀手就出现了。oom killer会在系统内存耗尽的情况下跳出来,选择性的干掉一些进程以求释放一点内存。

所以这时候我们的Java进程,是操作系统“主动”终结的,JVM连发表遗言的机会都没有。这个信息,只能在操作系统日志里找。

要解决这种问题,首先不能太贪婪。比如一共8GB的机器,你把整整7.5GB分配给了JVM。当操作系统内存不足,你的JVM就可能成为oom-killer的猎物。

不过,通过下面的命令,可以让进程避免被审判。

echo -17 > /proc/[PID]/oom_adj

这是因为,oom_adj文件,就是进程被oom killer杀掉的权重,一般介于 [-17,15]之间。越高的权重,意味着更可能被oom killer选中。

一旦你这么做,你的Java进程就是特权阶层了,可以无视规则。

2. 执行了上帝函数

xjjdog对这个函数的评价是:比你起认识它,还不如你不认识它。

这位函数你不要瞅我。说的就是你,System.exit。

这个函数危险得很,它将强制终止我们的应用,而且什么都不会留下。你应该扫描你的代码,确保这样的逻辑不会存在。

相信我,你并没有需要用程序判断来立即结束进程的需求,业务系统尤其没有。如果有,那大概率是不合理的。除非你把Java当脚本用了。

这个函数,是一个非常高级的埋坑技能,尤其是在Android之类的应用中。应用程序崩溃,你将什么原因都分析不到,哪怕你做了ShutdownHook。

buyaoluanyongwo

使用exit函数,一定要心存善意。

当然我们并不是对此束手无策。下面这段代码,就可以阻止exit的执行,霸道非凡。上帝的那只手,也给掰回去。

import java.security.Permission;

public class S {
    private static class ExitTrappedException extends SecurityException {
    }
    private static void forbidSystemExitCall() {
        final SecurityManager securityManager = new SecurityManager() {
            public void checkPermission(Permission permission) {
                if (permission.getName().startsWith("exitVM")) {
                    throw new ExitTrappedException();
                }
            }
        };
        System.setSecurityManager(securityManager);
    }
    private static void enableSystemExitCall() {
        System.setSecurityManager(null);
    }
    public static void main(String[] args) {
        forbidSystemExitCall();
        try {
            System.exit(0);
        }catch (Exception ex){
            ex.printStackTrace();
        }
        System.out.println("谢谢xjjjdog, 我依然能够执行");
    }
}

如果你用尽千方百计,都找不到异常终止的原因,试试挂上这段代码吧。有可能是救命的哦。

3. 错误的启动方式

再聊一种最初级最常见还经常发生的一种情况,会造成应用程序的意外死亡:那就是对Java程序错误的启动方式。

很多同学对Linux不是很熟悉,使用XShell登陆之后,调用下面的命令进行启动。

java com.cn.AA &

这位同学还算有点意识,在最后使用了&号,以期望进程在后台运行。但可惜的是,很多情况下,随着XShell Tab页的关闭,或者等待超时,后面的Java进程就随着一块停止了,很让人困惑。

正确的启动方式,就是使用nohup关键字,或者阻塞在其他更加长命的进程里(比如docker)。

nohup java com.cn.AA &

所以,当你登录上终端tty的时候,一定要闹明白当前执行的父进程是谁。你可能是所有接下来要运行的所有进程的祖先哦。

4.日志配置错误

如果上面的原因都不是,那大概率是你的项目里面日志框架的配置错误了。Java中的日志框架繁多,配置方式多样,一不小心,就会踩坑。即使你用的是SpringBoot,也会因为依赖包的问题,造成启动问题。

日志配置错误+异常情况,当然是什么都不会留下。

使用下面的命令,可以将依赖树转移到log文件里进行分析。

mvn dependency:tree > dep.log

如果是SpringBoot项目,是可以给main类加点代码的。

public static void main(String[] args) {
  try {
   SpringApplication.run(LinkpowerDtulockApplication.class, args);
  } catch (Exception e) {
   System.out.println(e);
  }
}

这样有什么异常情况,就可以早点发现。

End

另外,还有一些千奇百怪的原因。比如磁盘满了,句柄不够了,这些情况都很隐蔽,需要你精确把控系统的细节。

进程这种静悄悄的死亡方式,通常会给我们的问题排查带来更多的困难。

通常,我们在关闭服务的时候,会使用“kill -15”,而不是“kill -9”,以便让服务在临死之前喘口气。但并不总是有效,因为程序压根就没有机会发表遗言,有更高级别的存在阻止了它。Java进程横死,我们只能寻找其他手段。

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

本文分享自微信公众号 - 小姐姐味道(xjjdog) ,作者:小姐姐养的狗

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间: 2020-12-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

版权声明
本文为[xjjdog]所创,转载请带上原文链接,感谢
https://cloud.tencent.com/developer/article/1764801

Scroll to Top