System.exit() 会强制终止JVM进程，跳过所有清理逻辑，导致数据丢失、事务中断、连接泄漏及分布式异常；应改用finish()、WorkManager、实时保存和Spring Boot优雅停机等替代方案。
System.exit() 不是退出按钮，而是直接拔掉电源——它会瞬间终止整个 JVM 进程，跳过所有本该执行的清理逻辑。这种“硬终止”在数据敏感场景下极易引发数据丢失和事务中断，且后果往往滞后显现、难以回溯。
未保存数据立即蒸发
Android 或 Java 应用中，用户填写的表单、编辑的文档、临时缓存的状态，若依赖 Activity 的 onPause()、onSaveInstanceState() 或 SharedPreferences 的 apply() 异步提交，System.exit(0) 会直接跳过这些回调：
- SharedPreferences 中尚未 flush 到磁盘的修改（尤其是调用
edit().putString(...).apply()后立即 exit）会彻底丢失 - 数据库事务若处于 commit 前的 prepare 阶段，连接被强制断开，写入不生效也不回滚
- 文件写入流未 close，缓冲区内容未刷盘，目标文件可能为空或截断
- ViewModel 中保存的 UI 状态、LiveData 缓存的数据，因 onDestroy() 被跳过而无法持久化
事务与连接中途腰斩
在服务端或带后台任务的 Android 应用中，System.exit 会粗暴打断正在运行的业务链路：
- 数据库连接池中的活跃连接不会被归还或关闭，导致连接泄漏，后续请求可能因连接耗尽而超时
- 正在进行的事务既不 commit 也不 rollback，数据库可能留下脏数据或锁等待，影响一致性
- RxJava 或 Coroutine 的异步任务、Handler.postDelayed 的延迟操作、AlarmManager 设置的定时器，全部被无通知终止
- 网络请求响应回调（如 OkHttp Callback、Retrofit Call.enqueue）永远不会触发，上层无法感知失败或重试
更隐蔽的连锁反应
风险不仅限于当前进程，还会通过系统机制扩散：
- Android 中，若 Service 正在播放音乐或上传文件，exit 会导致通知栏残留、前台服务状态异常，下次启动可能因状态不一致报错
- 在 Spring Boot 或 Tomcat 环境中，exit 会绕过 Actuator 的 shutdown 端点、跳过 @PreDestroy 方法、忽略连接池 graceful shutdown，造成下游服务持续收不到响应
- 分布式环境下，节点突然消失可能触发注册中心剔除、负载均衡重平衡、消息队列位点停滞，引发雪崩式超时与堆积
真正可控的替代方案
避免数据丢失和事务中断，关键不是让 exit “更安全”，而是根本不用它：
- Activity 页面退出：调用
finish()，让系统按生命周期自然回收；栈清空后进程由系统决定是否保留 - 后台任务管理：使用 WorkManager 或 JobIntentService，交由系统调度；退出前调用
cancelAllWork()主动终止 - 数据持久化：对关键输入，在 onUserLeaveHint() 或 TextWatcher 中实时 save；敏感操作前先 commit 再 proceed
- 服务端优雅停机：Spring Boot 用
SpringApplication.exit(context, 0)，触发 Bean 销毁与连接释放；Tomcat 配置shutdownTimeout
