单个Java线程是否会导致整个JVM崩溃？JNI死锁致进程挂起是否阻塞全JVM？

这得分两种场景来看：

• 纯Java线程：绝对不会。哪怕这个线程抛出了未捕获的OutOfMemoryError、StackOverflowError这类致命错误，JVM只会终止这个出问题的线程，其他线程该执行还是执行——Java的线程隔离设计就是为了避免单个线程的错误牵连整个进程。
• 涉及JNI调用的线程：有可能直接搞崩整个JVM。因为JNI调用的本地代码（比如C/C++）是直接在操作系统层面运行的，完全不受Java安全模型的约束：
  • 如果本地代码出现段错误（比如访问野指针）、栈溢出，或者主动调用了abort()、exit()这类终止进程的函数，操作系统会直接给JVM进程发送终止信号，整个JVM瞬间崩溃。
  • 举个简单的例子：在JNI方法里写一行*(int*)0 = 0;，运行后JVM会直接因为SIGSEGV信号挂掉，没有任何挽回的余地。

这个不能一概而论，核心看死锁有没有牵扯到JVM的关键资源：

• 死锁仅在本地代码内部，未触碰JVM资源：这种情况只会影响陷入死锁的线程。比如两个调用JNI的Java线程，在本地代码里互相持有对方需要的本地锁，完全没用到JVM的内部锁（比如JNI全局锁、GC相关锁），那只有这两个线程会挂死，其他Java线程、JVM的后台线程（比如GC、JIT编译线程）都能正常工作，整个JVM不会被阻塞。
• 死锁涉及JVM的核心锁/资源：那整个JVM大概率会被卡住。比如本地代码在死锁时持有了JNI全局锁（部分JVM实现中，JNI方法执行时会自动加这个锁），或者阻塞了GC需要访问的内存区域，或者占用了JVM信号处理的关键资源：
  • 其他想要调用JNI的Java线程会因为拿不到锁而阻塞；
  • GC线程如果需要和本地代码交互（比如扫描本地代码引用的Java对象），也会被卡停；
  • 严重时，整个JVM的所有线程都会陷入阻塞状态，进程看起来完全挂死，只能通过操作系统强制终止。

内容的提问来源于stack exchange，提问作者alpha0