您当前的位置:首页 > 电脑百科 > 程序开发 > 语言 > JAVA

美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

时间:2022-06-16 12:02:21  来源:微信公众号  作者:Java高级互联小课堂
美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

 

大家好,我是坤哥

网上看到一个很有意思的美团面试题:为什么线程崩溃崩溃不会导致 JVM 崩溃,这个问题我看了不少回答,但发现都没答到根上,所以决定答一答,相信大家看完肯定会有收获,本文分以下几节来探讨

  1. 线程崩溃,进程一定会崩溃吗
  2. 进程是如何崩溃的-信号机制简介
  3. 为什么在 JVM 中线程崩溃不会导致 JVM 进程崩溃
  4. openJDK 源码解析

线程崩溃,进程一定会崩溃吗

一般来说如果线程是因为非法访问内存引起的崩溃,那么进程肯定会崩溃,为什么系统要让进程崩溃呢,这主要是因为在进程中,各个线程的地址空间是共享的,既然是共享,那么某个线程对地址的非法访问就会导致内存的不确定性,进而可能会影响到其他线程,这种操作是危险的,操作系统会认为这很可能导致一系列严重的后果,于是干脆让整个进程崩溃

美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

 

线程共享代码段,数据段,地址空间,文件

非法访问内存有以下几种情况,我们以 C 语言举例来看看

  1. 针对只读内存写入数据
  2. #include <stdio.h>
    #include <stdlib.h>
    int main() {
    char *s = "hello world";// 向只读内存写入数据,崩溃
    s[1] = 'H';
    }
  3. 访问了进程没有权限访问的地址空间(比如内核空间)
  4. #include <stdio.h>
    #include <stdlib.h>
    int main() {
    int *p = (int *)0xC0000fff; // 针对进程的内核空间写入数据,崩溃
    *p = 10;
    }
  5. 在 32 位虚拟地址空间中,p 指向的是内核空间,显然不具有写入权限,所以上述赋值操作会导致崩溃
  6. 访问了不存在的内存,比如
  7. #include <stdio.h>
    #include <stdlib.h>
    int main() {
    int *a = NULL;
    *a = 1;
    }

以上错误都是访问内存时的错误,所以统一会报 Segment Fault 错误(即段错误),这些都会导致进程崩溃

进程是如何崩溃的-信号机制简介

那么线程崩溃后,进程是如何崩溃的呢,这背后的机制到底是怎样的,答案是信号,大家想想要干掉一个正在运行的进程是不是经常用 kill -9 pid 这样的命令,这里的 kill 其实就是给指定 pid 发送终止信号的意思,其中的 9 就是信号,其实信号有很多类型的,在 linux 中可以通过 kill -l查看所有可用的信号

美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

 

当然了发 kill 信号必须具有一定的权限,否则任意进程都可以通过发信号来终止其他进程,那显然是不合理的,实际上 kill 执行的是系统调用,将控制权转移给了内核(操作系统),由内核来给指定的进程发送信号

那么发个信号进程怎么就崩溃了呢,这背后的原理到底是怎样的?

其背后的机制如下

  1. CPU 执行正常的进程指令
  2. 调用 kill 系统调用向进程发送信号
  3. 进程收到操作系统发的信号,CPU 暂停当前程序运行,并将控制权转交给操作系统
  4. 调用 kill 系统调用向进程发送信号(假设为 11,即 SIGSEGV,一般非法访问内存报的都是这个错误)
  5. 操作系统根据情况执行相应的信号处理程序(函数),一般执行完信号处理程序逻辑后会让进程退出

注意上面的第五步,如果进程没有注册自己的信号处理函数,那么操作系统会执行默认的信号处理程序(一般最后会让进程退出),但如果注册了,则会执行自己的信号处理函数,这样的话就给了进程一个垂死挣扎的机会,它收到 kill 信号后,可以调用 exit() 来退出,但也可以使用 sigsetjmp,siglongjmp 这两个函数来恢复进程的执行

// 自定义信号处理函数示例

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
// 自定义信号处理函数,处理自定义逻辑后再调用 exit 退出
void sigHandler(int sig) {
  printf("Signal %d catched!n", sig);
  exit(sig);
}
int main(void) {
  signal(SIGSEGV, sigHandler);
  int *p = (int *)0xC0000fff;
  *p = 10; // 针对不属于进程的内核空间写入数据,崩溃
}

// 以上结果输出: Signal 11 catched!

如代码所示:注册信号处理函数后,当收到 SIGSEGV 信号后,先执行相关的逻辑再退出

另外当进程接收信号之后也可以不定义自己的信号处理函数,而是选择忽略信号,如下

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>

int main(void) {
  // 忽略信号
  signal(SIGSEGV, SIG_IGN);

  // 产生一个 SIGSEGV 信号
  raise(SIGSEGV);

  printf("正常结束");
}

也就是说虽然给进程发送了 kill 信号,但如果进程自己定义了信号处理函数或者无视信号就有机会逃出生天,当然了 kill -9 命令例外,不管进程是否定义了信号处理函数,都会马上被干掉

说到这大家是否想起了一道经典面试题:如何让正在运行的 JAVA 工程的优雅停机,通过上面的介绍大家不难发现,其实是 JVM 自己定义了信号处理函数,这样当发送 kill pid 命令(默认会传 15 也就是 SIGTERM)后,JVM 就可以在信号处理函数中执行一些资源清理之后再调用 exit 退出。这种场景显然不能用 kill -9,不然一下把进程干掉了资源就来不及清除了

为什么线程崩溃不会导致 JVM 进程崩溃

现在我们再来看看开头这个问题,相信你多少会心中有数,想想看在 Java 中有哪些是常见的由于非法访问内存而产生的 Exception 或 error 呢,常见的是大家熟悉的 StackoverflowError 或者 NPE(NullPointerException),NPE 我们都了解,属于是访问了不存在的内存

但为什么栈溢出(Stackoverflow)也属于非法访问内存呢,这得简单聊一下进程的虚拟空间,也就是前面提到的共享地址空间

现代操作系统为了保护进程之间不受影响,所以使用了虚拟地址空间来隔离进程,进程的寻址都是针对虚拟地址,每个进程的虚拟空间都是一样的,而线程会共用进程的地址空间,以 32 位虚拟空间,进程的虚拟空间分布如下

美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

 

那么 stackoverflow 是怎么发生的呢,进程每调用一个函数,都会分配一个栈桢,然后在栈桢里会分配函数里定义的各种局部变量,假设现在调用了一个无限递归的函数,那就会持续分配栈帧,但 stack 的大小是有限的(Linux 中默认为 8 M,可以通过 ulimit -a 查看),如果无限递归很快栈就会分配完了,此时再调用函数试图分配超出栈的大小内存,就会发生段错误,也就是 stackoverflowError

美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

 

好了,现在我们知道了 StackoverflowError 怎么产生的,那问题来了,既然 StackoverflowError 或者 NPE 都属于非法访问内存, JVM 为什么不会崩溃呢,有了上一节的铺垫,相信你不难回答,其实就是因为 JVM 自定义了自己的信号处理函数,拦截了 SIGSEGV 信号,针对这两者不让它们崩溃,怎么证明这个推测呢,我们来看下 JVM 的源码来一探究竟

openJDK 源码解析

HotSpot 虚拟机目前使用范围最广的 Java 虚拟机,据 R 大所述, Oracle JDK 与 OpenJDK 里的 JVM 都是 HotSpot VM,从源码层面说,两者基本上是同一个东西,OpenJDK 是开源的,所以我们主要研究下 Java 8 的 OpenJDK 即可,地址如下:
https://github.com/AdoptOpenJDK/openjdk-jdk8u,有兴趣的可以下载来看看

我们只要研究 Linux 下的 JVM,为了便于说明,也方便大家查阅,我把其中关于信号处理的关键流程整理了下(忽略其中的次要代码)

美团一面:为什么线程崩溃崩溃不会导致 JVM 崩溃

 

可以看到,在启动 JVM 的时候,也设置了信号处理函数,收到 SIGSEGV,SIGPIPE 等信号后最终会调用 JVM_handle_linux_signal 这个自定义信号处理函数,再来看下这个函数的主要逻辑

JVM_handle_linux_signal(int sig,
                        siginfo_t* info,
                        void* ucVoid,
                        int abort_if_unrecognized) {

   // Must do this before SignalHandlerMark, if crash protection installed we will longjmp away
  // 这段代码里会调用 siglongjmp,主要做线程恢复之用
  os::ThreadCrashProtection::check_crash_protection(sig, t);

  if (info != NULL && uc != NULL && thread != NULL) {
    pc = (address) os::Linux::ucontext_get_pc(uc);

    // Handle ALL stack overflow variations here
    if (sig == SIGSEGV) {
      // Si_addr may not be valid due to a bug in the linux-ppc64 kernel (see
      // comment below). Use get_stack_bang_address instead of si_addr.
      address addr = ((NativeInstruction*)pc)->get_stack_bang_address(uc);

      // 判断是否栈溢出了
      if (addr < thread->stack_base() &&
          addr >= thread->stack_base() - thread->stack_size()) {
        if (thread->thread_state() == _thread_in_Java) {
            // 针对栈溢出 JVM 的内部处理
            stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::STACK_OVERFLOW);
        }
      }
    }
  }

  if (sig == SIGSEGV &&
               !macroAssembler::needs_explicit_null_check((intptr_t)info->si_addr)) {
         // 此处会做空指针检查
      stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::IMPLICIT_NULL);
  }


  // 如果是栈溢出或者空指针最终会返回 true,不会走最后的 report_and_die,所以 JVM 不会退出
  if (stub != NULL) {
    // save all thread context in case we need to restore it
    if (thread != NULL) thread->set_saved_exception_pc(pc);

    uc->uc_mcontext.gregs[REG_PC] = (greg_t)stub;
    // 返回 true 代表 JVM 进程不会退出
    return true;
  }

  VMError err(t, sig, pc, info, ucVoid);
  // 生成 hs_err_pid_xxx.log 文件并退出
  err.report_and_die();

  ShouldNotReachHere();
  return true; // Mute compiler

}

从以上代码(注意看加粗的红线字体部分)我们可以知道以下信息

  1. 发生 stackoverflow 还有空指针错误,确实都发送了 SIGSEGV,只是虚拟机不选择退出,而是自己内部作了额外的处理,其实是恢复了线程的进程,并抛出 StackoverflowError 和 NPE,这就是为什么 JVM 不会崩溃且我们能捕获这两个错误/异常的原因
  2. 如果针对 SIGSEGV 等信号,在以上的函数中 JVM 没有做额外的处理,那么最终会走到 report_and_die 这个方法,这个方法主要做的事情是生成 hs_err_pid_xxx.log crash 文件(记录了一些堆栈信息或错误),然后退出

至此我相信大家明白了为什么发生了 StackoverflowError 和 NPE 这两个非法访问内存的错误,JVM 却没有崩溃。原因其实就是虚拟机内部定义了信号处理函数,而在信号处理函数中对这两者做了额外的处理以让 JVM 不崩溃,另一方面也可以看出如果 JVM 不对信号做额外的处理,最后会自己退出并产生 crash 文件 hs_err_pid_xxx.log(可以通过 -XX:ErrorFile=/var/log/hs_err.log 这样的方式指定),这个文件记录了虚拟机崩溃的重要原因,所以也可以说,虚拟机是否崩溃只要看它是否会产生此崩溃日志文件

总结

正常情况下,操作系统为了保证系统安全,所以针对非法内存访问会发送一个 SIGSEGV 信号,而操作系统一般会调用默认的信号处理函数(一般会让相关的进程崩溃),但如果进程觉得"罪不致死",那么它也可以选择自定义一个信号处理函数,这样的话它就可以做一些自定义的逻辑,比如记录 crash 信息等有意义的事,回过头来看为什么虚拟机会针对 StackoverflowError 和 NullPointerException 做额外处理让线程恢复呢,针对 stackoverflow 其实它采用了一种栈回溯的方法保证线程可以一直执行下去,而捕获空指针错误主要是这个错误实在太普遍了,为了这一个很常见的错误而让 JVM 崩溃那线上的 JVM 要宕机多少次,所以出于工程健壮性的考虑,与其直接让 JVM 崩溃倒不如让线程起死回生,并且将这两个错误/异常抛给用户来处理

 

原文链接:
https://mp.weixin.qq.com/s/JnlTdUk8Jvao8L6FAtKqhQ



Tags:JVM   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
大家好,我是坤哥网上看到一个很有意思的美团面试题:为什么线程崩溃崩溃不会导致 JVM 崩溃,这个问题我看了不少回答,但发现都没答到根上,所以决定答一答,相信大家看完肯定会有收获...【详细内容】
2022-06-16  Tags: JVM  点击:(48)  评论:(0)  加入收藏
企业级应用开发中经常会遇到以下问题,可以使用工具对JVM进行监管,以便及时查找问题所在。   内存不足OutOfMemory(大对象没有gc等),内存泄露;   线程死锁,线程数过多;   锁争...【详细内容】
2022-05-07  Tags: JVM  点击:(43)  评论:(0)  加入收藏
这篇文章中介绍下如何使用 JDK 自带工具来分析和定位 Java 程序的问题。使用 JDK 自带工具查看 JVM 情况JDK 自带了很多命令行甚至是图形界面工具,帮助我们查看 JVM 的一些信...【详细内容】
2022-04-15  Tags: JVM  点击:(67)  评论:(0)  加入收藏
Thread Dump介绍Thread Dump是非常有用的诊断Java应用问题的工具。每一个Java虚拟机都有及时生成所有线程在某一点状态的thread-dump的能力,虽然各个 Java虚拟机打印的thread...【详细内容】
2021-01-18  Tags: JVM  点击:(205)  评论:(0)  加入收藏
1. 前言熟练掌握 MAT 是 Java 高手的必备能力,但实践时大家往往需面对众多功能,眼花缭乱不知如何下手,小编也没有找到一篇完善的教学素材,所以整理本文帮大家系统掌握 MAT 分析...【详细内容】
2020-12-31  Tags: JVM  点击:(180)  评论:(0)  加入收藏
1. Java 堆空间发生频率:5颗星造成原因 无法在 Java 堆中分配对象 吞吐量增加 应用程序无意中保存了对象引用,对象无法被 GC 回收 应用程序过度使用 finalizer。finalizer 对...【详细内容】
2019-10-22  Tags: JVM  点击:(213)  评论:(0)  加入收藏
00 前言Java程序具有 " Write Once , Run Anywhere ." 的跨平台特性。实现这样的目的,Java的方案是:半编译 + 半解释,即 .Class + JVM 。 1、源程序内容会被编译为.Class文件,.C...【详细内容】
2019-10-15  Tags: JVM  点击:(184)  评论:(0)  加入收藏
【1】JDK、JRE、JVM区别与联系JVM :英文名称(Java Virtual Machine),就是我们耳熟能详的 Java 虚拟机。它只认识 xxx.class 这种类型的文件,它能够将 class 文件中的字节码指令进...【详细内容】
2019-09-24  Tags: JVM  点击:(190)  评论:(0)  加入收藏
▌简易百科推荐
本文的目的是演示一个专门设计用于对收据照片执行OCR(光学字符识别)操作并自动从中提取关键业务信息的 API,例如企业名称和地址、电话号码、收据总额等等。在页面的下方,我提供...【详细内容】
2022-07-15  qaseven    Tags: OCR   点击:(2)  评论:(0)  加入收藏
StackOverflowError 可能会让Java开发人员感到恼火,因为它是我们可能遇到的最常见的运行时错误之一。在本文中,我们将通过查看各种代码示例以及如何处理它来了解此错误是如何...【详细内容】
2022-07-14  java程序猿    Tags:StackOverflowError   点击:(5)  评论:(0)  加入收藏
写在前面无意中看到ch1ng师傅的文章觉得很有趣,不得不感叹师傅太厉害了,但我一看那长篇的函数总觉得会有更骚的东西,所幸还真的有,借此机会就发出来一探究竟,同时也不得不感慨下R...【详细内容】
2022-07-13  江江111  今日头条  Tags:waf 绕过   点击:(4)  评论:(0)  加入收藏
今早,看到CSDN里推荐的Python获取女朋友发来加班拍照定位地址是酒店的段子,本来准备验证下,顺便练练手的,最后,安装执行pip install json报没有指定版本号。一怒之下搞我大JAVA,验...【详细内容】
2022-07-12  java小悠    Tags:Java 技术   点击:(8)  评论:(0)  加入收藏
核心代码:import java.util.Map;import java.util.List;import java.util.Iterator;import java.util.ArrayList;import java.io.IOException;import java.io.InputStream;im...【详细内容】
2022-07-12  编程课堂    Tags:Java Post   点击:(10)  评论:(0)  加入收藏
上半年春招的时候,作为面试官,对于面试表现的不错的同学会要求其写一小段代码看看。题目很简单:给定一个日期,然后计算下距离今天相差的天数。本以为这么个问题就是用来活跃面试...【详细内容】
2022-07-11  架构悟道    Tags:JAVA   点击:(11)  评论:(0)  加入收藏
跳表是一种数据结构,用于借助连接到元素子序列的链表层次结构来存储元素的排序列表。跳表允许以有效的方式处理项目查找。跳表是一种概率数据结构,这意味着它跳过整个列表中的...【详细内容】
2022-07-08  java程序猿    Tags:跳表   点击:(13)  评论:(0)  加入收藏
概述背景是不是在实际开发工作当中经常碰到自己写的代码在开发、测试环境行云流水稳得一笔,可一到线上就经常不是缺这个就是少那个反正就是一顿报错抽风似的,线上调试代码又很...【详细内容】
2022-07-08  程序猿的自述    Tags:Arthas   点击:(16)  评论:(0)  加入收藏
我之前分享了Java和Go语言版本的gRPC接口的服务端和客户端的开发,使用的基本都是基础的原声API,旧文如下: Grpc服务开发和接口测试初探【Java】 2022-04-20 gRPC服务开发和接口...【详细内容】
2022-07-07  FunTester    Tags:gRPC   点击:(16)  评论:(0)  加入收藏
Linux下启动Java程序的脚本程序startup.sh#!/bin/bashnohup java -Djava.security.egd=file:/dev/./urandom -Xms512m -Xmx512m -XX:MetaspaceSize=128M -XX:MaxMetaspaceSi...【详细内容】
2022-07-07  精科研习    Tags:Java   点击:(23)  评论:(0)  加入收藏
站内最新
站内热门
站内头条