应避免在核心流操作中滥用状态码退出，因其会绕过资源清理、中断状态快照、跳过finally与钩子，导致连接泄漏、OOM Killer触发、虚拟机被强制挂起或重置；推荐返回错误信号、抛出受检异常或降级至死信队列。
在核心流操作分支中滥用状态码退出（如 exit(1)、System.exit(1)），表面看只是进程返回一个数字，实际会绕过所有资源清理流程，在高并发流处理场景下快速引发虚拟机提前终止。根本原因不是退出动作本身，而是它暴露并放大了底层资源失控与状态不一致问题。
流操作上下文被强制截断，共享资源持续泄漏
流式处理常依赖共享缓冲区、连接池、事件循环、计数器或锁等有状态组件。一旦在某个分支中调用状态码退出：
- 未释放的网络连接、文件句柄、内存映射区不会被回收，持续堆积直至耗尽宿主机
ulimit -n或vm.max_map_count - 流式框架（如 Flink 的 TaskManager、Kafka Streams 的 StreamThread）内部维护的状态快照、checkpoint barrier、watermark 等机制被中断，导致后续恢复失败
- Java 场景下，
System.exit()跳过finally、try-with-resources和Runtime.addShutdownHook()，Netty EventLoop、数据库连接池、日志异步队列全部丢失上下文
高频短命进程触发宿主机保护性干预
当流处理任务因数据异常、反压超时或校验失败而频繁触发退出时，虚拟机内会出现大量“秒级生命周期”的进程：
- Linux 内核需反复回收
task_struct、页表、cgroup 配额，调度开销剧增，vCPU 利用率虚高但有效吞吐归零 - 若伴随未释放的
mmap区域，OOM Killer 可能将整个虚拟机进程（如qemu-kvm）标记为内存异常源，直接发送SIGKILL（退出码 137） - VMware/ESXi 监控到
vmtoolsd或vmmemctl异常退出率突增，判定虚拟机不可信，主动 suspend 或 power off 实例
与底层硬件行为耦合，加剧系统级卡死
在多核虚拟机中，流操作常涉及原子计数、CAS 校验、跨线程状态同步。若退出前执行了未对齐的原子操作（例如指针落在 cacheline 末尾的 lock inc）：
- 触发 split lock，CPU 广播总线锁，阻塞其他核心达微秒级
- 多个流线程反复争抢同一 cache line，形成全局性能雪崩，vCPU 长期处于
VMX_ROOT状态且响应延迟超标 - 宿主机监控系统判定为“不可恢复卡死”，强制重置虚拟机
替代方案更契合流式语义
流操作本质是持续、可恢复、带状态的数据转换过程，应避免进程级终结：
- 返回错误信号：用
Optional.empty()、Either.left(error)或自定义StreamResult.failure("invalid timestamp") - 抛出受检异常：如
throw new DataValidationException("out-of-order event")，由流框架统一捕获、跳过、告警或重试 - 降级处理：标记脏数据进入死信队列（DLQ），保持主链路畅通
- 优雅熔断：通过
FlowControlSignal主动暂停子流，而非杀死整个运行时
