ArithmeticException 本身不是高并发性能瓶颈，真正拖慢系统的是频繁抛出和捕获它，因栈展开、异常对象创建、堆栈跟踪填充及GC压力显著抬高CPU开销。
ArithmeticException 本身不是高并发下的性能瓶颈，真正拖慢系统的，是频繁抛出和捕获它。JVM 每次 throw/catch 都涉及栈展开、异常对象创建、填充堆栈跟踪（stack trace），在每秒数千笔交易的财务系统中，这会显著抬高 CPU 开销和 GC 压力。
为什么 catch 不是高性能解法
异常机制设计初衷是处理“异常情况”，而非控制流。在高并发场景下：
- 每次除零或溢出检查失败都会触发完整异常流程，开销远高于一次 if 判断
- 堆栈跟踪默认记录全部调用链，字符串拼接与内存分配带来额外负担
- 大量短生命周期的 ArithmeticException 对象涌入 Eden 区，加剧 Minor GC 频率
- 同步捕获并打印日志（尤其是 e.printStackTrace()）会阻塞线程，放大延迟
高频触发的真实来源
不是业务逻辑写错了，而是防护层缺失或错位：
- 外部输入未过滤：API 或 CSV 导入的费率、数量字段为 0 或超大值，直接进入核心计算
- 误用原生整型：用 long 存累计余额，但未用 Math.addExact()，溢出后静默变负，后续校验失败才抛异常
- 校验点太靠后：把除数检查放在 DAO 层或记账前最后一刻，而非在 Controller 或 DTO 解析时就拦截
- 重复校验：同一笔订单在风控、计费、对账多个环节都做相同除零判断，却没缓存结果
不拖慢吞吐量的应对方式
目标是让绝大多数请求“零异常”通过：
立即学习“Java免费学习笔记（深入）”；
- 前置硬校验：在参数解析阶段（如 Spring @Valid + 自定义 ConstraintValidator）拒绝 divisor == 0 或金额为负的请求，返回 400
- 零开销边界检查：对确定走整型路径的乘法，用 if (a > 0 && b > 0 && a > Long.MAX_VALUE / b) 替代 Math.multiplyExact()
- 异步告警通道：真捕获到 ArithmeticException 时，只发轻量 Kafka 事件（含订单 ID、原始值、时间戳），不记录完整堆栈，不阻塞主流程
- 缓存可信值：对第三方接口返回的固定费率，用 Redis 缓存其有效性（如 supplier_id:fee_valid = true），命中即跳过运行时检查
关键取舍原则
性能与安全不矛盾，但需分层承担成本：
- 用户输入层 —— 用 BigDecimal 解析+精度校验，成本由单次请求承担
- 核心运算层 —— 用 Math.*Exact()，只在风控闸口集中使用，非每行都包 try-catch
- 数据持久层 —— 数据库加 CHECK 约束（如 amount >= 0），从源头堵住非法状态
- 监控层 —— 对 ArithmeticException 做分钟级聚合告警，而不是逐条日志落盘
