NullPointerException 在对 null 执行非空语义操作（如调用方法、访问字段、同步块等）时抛出，JVM 在 getfield、invokevirtual 等指令执行时校验 null 并立即触发异常。
NullPointerException 什么时候真正抛出
不是所有 null 赋值都会立刻报错，NullPointerException 只在「对 null 做非空语义操作」的瞬间触发。比如 obj.toString()、arr.length、str.charAt(0)、list.add(x) —— 这些调用都隐含「假设接收者非 null」的前提。
常见误判：给字段赋 null、方法返回 null、集合里存 null，这些本身不抛异常；只有后续试图解引用它时才崩。
-
String s = null;✅ 合法 -
int len = s.length();❌ 立即抛NullPointerException -
if (s != null && s.length() > 0)✅ 短路保护，不会触发
字节码层面的触发点在哪
JVM 在执行 getfield、invokevirtual、invokeinterface、checkcast 等指令时，会校验对象引用是否为 null。一旦发现栈顶或局部变量表中对应位置是 null，就直接抛出异常，不进入方法体或字段读取逻辑。
这意味着：即使方法体第一行是 System.out.println("start")，只要调用的是 null 对象的方法，这行根本不会执行。
立即学习“Java免费学习笔记（深入）”；
-
invokevirtual是最常见触发点（普通实例方法调用） -
getfield和putfield在访问实例字段时也会检查（如obj.field） -
monitorenter（即synchronized(obj)）同样会判空，synchronized(null)也抛 NPE
哪些看似安全的操作其实暗藏风险
有些写法容易让人误以为“已判空”，实则仍有漏洞。尤其在链式调用、自动拆箱、增强 for 循环等场景下。
-
user.getAddress().getCity().toUpperCase()：前面任一环节返回null都崩，推荐用Objects.requireNonNull()或Optional显式表达意图 -
Integer i = null; int x = i + 1;：自动拆箱触发 NPE，比i.toString()更隐蔽 -
for (String s : list)：若list本身为null，会在迭代器创建阶段（list.iterator()）抛 NPE -
String.format("%s", obj)：如果obj是null，格式化本身不崩，但若模板里有%d却传了null，拆箱时崩
为什么 try-catch 捕获不到某些 NPE
不是所有 NPE 都能被 Java 层的 catch (NullPointerException e) 捕获。JVM 规范允许将部分空指针检查优化掉，尤其是当 JIT 编译器能静态证明某次访问必不为空时，可能省略运行时检查 —— 这种情况下，NPE 不会出现；但反过来说，若 JIT 在某个编译版本中做了激进优化（比如内联后误判），也可能导致异常行为变化。
更实际的风险是：某些底层 native 方法或 JVM 内部操作（如 Unsafe 直接内存访问）引发的空指针，可能表现为 Segmentation fault 或直接 crash，而非标准 NullPointerException。
- 不要依赖
catch(NPE)做流程控制，它本就表示程序逻辑缺陷 - 单元测试要覆盖
null输入路径，而不是靠线上崩了再补 catch - 启用
-XX:+ShowMessageBoxOnError可在崩溃时弹窗，辅助定位 native 层空指针
null 的检查粒度很细，但正因如此，异常发生的位置和你代码里「看起来最近」的那行未必一致 —— 调用栈顶部显示的行号，只是检查失败后抛异常的位置，不是问题根源。查 NPE，得顺栈往回找谁给了 null，而不是盯着报错行修语法。 
