优化try-catch不直接降低响应耗时，关键在减少异常发生、精准捕获明确类型（如clientresponseexception、timeoutexception）、避免catch块中执行高开销操作，并用try-with-resources保障资源及时释放。
优化 try-catch 本身不直接降低响应耗时，关键在于避免它成为性能瓶颈或掩盖低效设计。真正影响微服务接口响应时间的，是异常被频繁抛出、捕获位置不当、以及在 catch 块中执行高开销操作。优化方向应聚焦于“减少异常发生”“精准捕获”和“轻量响应”，而非堆砌语法结构。
只在必要位置捕获明确异常类型
网关或 Controller 层不应用 catch (Exception e) 包裹整个请求处理链。这会吞掉 NPE、OOM 等致命问题，且每次捕获都触发堆栈展开，增加毫秒级延迟。应只捕获可预期、可策略化响应的异常：
- ClientResponseException：下游返回 4xx/5xx 时，直接映射为统一错误码（如 400→{"code":4001,"msg":"参数校验失败"}），不记录全堆栈，避免日志写入拖慢响应
- TimeoutException：立即返回 504 或触发降级，不重试、不查库、不打调试日志
- IllegalArgumentException：用于参数校验失败，走快速失败路径，不进入业务逻辑层
绝不把异常当流程控制使用
常见反模式会显著拉高 P99 延迟：
- 用
Integer.parseInt(str)+ catchNumberFormatException判断是否为数字 → 改用str.chars().allMatch(Character::isDigit)或正则预检 - 循环中逐条解析 JSON 字段并 try-catch → 先用 Jackson 的
JsonParser流式跳过非法字段，或用ObjectMapper.canDeserialize()预判 - 查数据库用
getOne()抛EmptyResultDataAccessException控制分支 → 改用countById()或existsById()，避免 ORM 构建完整实体和异常对象开销
catch 块内禁止执行耗时操作
一旦进入 catch，说明已发生故障，此时任何额外开销都会直接叠加到响应时间上：
- 不调用远程服务（如发告警短信、查用户画像）——这些应异步解耦或由监控系统主动拉取
- 不执行复杂日志拼接（如 JSON 序列化整个 request 对象）——改用结构化日志框架（如 Logback + JSON encoder），仅记录 traceId、errorType、httpStatus
- 不启动新线程或阻塞等待（如
Thread.sleep(100)重试）——重试必须由 Resilience4j 等组件在非临界路径完成
用 try-with-resources 替代手动 finally 释放
资源未及时关闭会导致连接池耗尽、线程阻塞，间接抬高后续所有请求的排队延迟：
- 数据库操作必须用
try (Connection c = ds.getConnection(); PreparedStatement ps = c.prepareStatement(sql)) { ... } - HTTP 客户端如 WebClient 自带连接复用，但自定义解码器中的
ByteBuffer、InputStream必须用 try-with-resources 管理 - Redis 调用中，Jedis 实例需确保 returnResource，RedissonClient 则依赖其自动管理；若手动获取，务必用 try-with-resources 或显式 close
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
