编译器是否拦截是唯一判断标准：受检异常不处理则编译失败，运行时异常编译通过、运行才抛；关键看继承链是否经过RuntimeException，而非类名或发生时机。

编译器是否拦你，是唯一判断标准：受检异常不处理就过不了编译，运行时异常爱抛不抛，编译器不管。

看编译器报错就能立刻分辨

写一行 new FileInputStream("missing.txt")，不加 try-catch 也不加 throws IOException，javac 直接报错：Unhandled exception type FileNotFoundException —— 这就是受检异常的强制性体现。而写 list.get(100)，哪怕 list 是空的，编译照样通过，运行才崩，因为 IndexOutOfBoundsException 是 RuntimeException 的子类。

关键不是“它会不会发生”，而是“编译器认不认识它该不该管”：

• 继承链最终落在 Exception 上，但**没经过 RuntimeException** → 受检异常
• 继承链里只要出现过 RuntimeException（哪怕只隔一层）→ 运行时异常
• Error 及其子类（如 OutOfMemoryError）既不是受检也不是运行时异常，编译器同样不检查，但你不该捕获它

为什么 InterruptedException 是个典型陷阱

InterruptedException 名字里没 “Runtime”，但它在 java.lang 包里，父类是 Exception，且**不是 RuntimeException 的后代** → 它是受检异常。很多人误以为“线程中断算运行时行为”，结果漏写处理，导致中断信号被静默吞掉，线程无法响应停止指令。

正确做法不是忽略，而是至少做两件事之一：

• 在方法签名中声明 throws InterruptedException，把责任往上传
• 捕获后调用 Thread.currentThread().interrupt() 恢复中断状态，而不是只打日志或什么都不做

漏掉第二步，等于把中断标记擦掉了，上层代码再也感知不到这个线程该停了。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

自定义异常时怎么选父类

选 Exception 还是 RuntimeException，取决于你希望调用方“必须面对”还是“可以忽略但不应掩盖”：

• 业务上可预期、需主动干预的失败（如余额不足、权限校验不通过）→ 继承 Exception，强制调用方决策：是重试、降级，还是向上抛？
• 程序明显写错了才触发的失败（如传入 null ID 调用 DAO、状态枚举值非法）→ 继承 RuntimeException，靠测试和代码审查提前暴露，而不是让每个调用点都写 try-catch

注意：不要为了“省事”把所有异常都做成运行时异常；也不要为了“严谨”把所有异常都做成受检异常——前者让错误沉默，后者让 API 被 throws 污染得没法用。

catch (Exception e) 是危险操作

这种写法表面兜底，实际会捕获到本不该你处理的东西：

• 可能拦下 OutOfMemoryError，导致 JVM 已经快崩了你还试图继续执行逻辑
• 可能吞掉 InterruptedException，中断语义彻底丢失
• 掩盖真实异常类型，调试时只剩一个泛泛的 e.printStackTrace()，看不出是空指针还是文件找不到

真正需要的，是按具体异常类型分层处理：比如 IOException 做重试，IllegalArgumentException 直接返回 400，SQLException 转成统一的数据访问异常再抛出。

最易被忽略的一点：受检异常的强制性只存在于编译期，JVM 运行时对两类异常的抛出、栈展开、性能开销完全一致。所谓“性能差”，纯属误解；所谓“必须处理”，也只是编译器在你写完代码那一刻拉住你问一句：“这个外部不确定性，你想怎么回应？”——答不上来，它就不让你交卷。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南