滥用状态码（如System.exit(1)）会强制终止整个进程，绕过资源清理机制，导致资源泄漏、状态不一致及系统级熔断。
在集合操作的分支中滥用状态码（如 exit(1)、System.exit(1)）不会直接“终止集合操作”，但会强制终止整个进程或虚拟机，其根本原因在于：它绕过了所有资源清理机制，在集合高频、共享、有状态的上下文中，迅速引发资源泄漏、状态不一致与系统级保护响应。
以下三点是关键逻辑链：
跳过集合相关资源的释放路径
集合操作常依赖外部状态：连接池中的数据库连接、Netty 的 EventLoop、缓存中的弱引用映射、并发计数器（如AtomicInteger）、锁（ReentrantLock）等。一旦在if (blackList.contains(user)) { System.exit(1); }这类分支中退出，finally块、try-with-resources、ShutdownHook全部失效，连接不关闭、锁不释放、内存不回收。尤其当 blackList 是大集合（如 10 万用户黑名单），该分支每秒触发数十次，几秒内就耗尽文件描述符或线程句柄。放大高并发下的状态撕裂风险
多线程访问同一集合（如static List<String> ROLES = ...）时，若某线程因校验失败而exit，其他线程可能正处在add()、iterator().remove()或 CAS 更新途中。此时 JVM 突然终止，未完成的原子操作中断，底层内存映射（mmap）、堆外缓冲区（DirectByteBuffer）残留，导致宿主机OOM Killer将整个 Java 进程（含qemu-kvm）标记为异常源，发出SIGKILL（状态码 137）。触发虚拟化层对“不可控短命进程”的熔断
在容器或虚拟机中运行的集合处理服务（如 Flink TaskManager、Spring Batch Worker），若因数据异常频繁调用System.exit，VMware/ESXi 会检测到vmtoolsd异常退出率飙升，判定该虚拟机“失去行为可控性”，主动 suspend 或 power off；Linux cgroup 也会因进程反复创建销毁，触发调度抖动与配额超限，最终由内核强制重置。
真正危险的不是“用了状态码”，而是在本应返回错误、降级、打标或入死信队列的地方，选择了进程终结——这违背了集合操作“可恢复、可重试、可审计”的本质语义。
不复杂但容易忽略
