Java异常本身不会直接拖垮系统，但处理不当会显著削弱稳定性——关键在响应方式：资源泄漏、异常掩盖、滥用异常、安全风险四大问题需分别通过try-with-resources、分层捕获+结构化日志、校验前置、泛化提示+熔断限流来应对。
Java异常本身不会直接拖垮系统，但处理不当会显著削弱稳定性——关键不在“有没有异常”，而在“怎么响应”。一次未捕获的空指针可能只让单个请求失败；而反复触发的IO异常若伴随资源未释放、日志泛滥或错误重试失控，就可能演变为线程阻塞、内存泄漏甚至服务雪崩。
资源泄漏：静默的性能杀手
文件句柄、数据库连接、网络Socket等资源若在异常路径中未关闭，会持续占用系统限额。例如手动new FileInputStream后仅用try-catch却没close，异常发生时连接悬空，累积后触发“Too many open files”。
- 始终优先使用try-with-resources（JDK7+），自动确保AutoCloseable资源释放
- 避免在finally块里调用可能再次抛异常的close()，改用Objects.requireNonNull()辅助判空
- 监控指标如ActiveConnections、FileDescriptorCount，异常上升时同步检查资源关闭逻辑
异常掩盖与误判：调试变盲区
用catch(Exception e)吞掉所有异常，或只打印e.printStackTrace()却不记录日志级别和上下文，会让真实问题沉底。比如本该是SQL语法错，却被笼统记为“操作失败”，排查时只能靠猜。
- 按异常类型分层捕获：先catch SQLException，再catch IOException，最后兜底Exception（如有必要）
- 日志必须包含：时间戳、业务ID、异常堆栈（生产环境脱敏）、关键参数（如用户ID、订单号）
- 禁用空catch块；至少记录warn或error级别日志，哪怕只是“忽略该格式错误”
异常滥用：把错误当流程控制
用NumberFormatException捕获字符串转数字失败来判断是否为数字，看似简洁，实则低效且易误伤——每次失败都触发完整堆栈生成，CPU和GC压力陡增。高频场景下，QPS可能下降30%以上。
立即学习“Java免费学习笔记（深入）”；
- 校验优先于捕获：用正则\\d+预筛、StringUtils.isNumeric()等轻量判断
- 避免在循环内抛/捕异常做分支逻辑，改用if-else或状态机
- 自定义异常仅用于真正“意外”场景，非业务规则分支
安全与可用性风险：从报错到被攻破
向前端返回原始异常消息（如“java.io.FileNotFoundException: /etc/passwd (Permission denied)”）等于主动暴露路径和权限细节；高频异常还可能被刷成DoS攻击入口。
- 用户侧统一返回泛化提示：“操作未成功，请稍后重试”，绝不含技术术语或路径
- 服务端日志保留完整堆栈，但过滤敏感字段（密码、token、完整SQL、IP段）
- 对高频异常（如1分钟内同接口超50次SQLException）触发限流或熔断，防止级联故障
基本上就这些。稳定不是没有异常，而是让每次异常都可定位、可收敛、不扩散。
