system.exit()不能自动释放端口，必须在shutdownhook中显式关闭监听套接字（如netty的serverchannel、bossgroup等），并设置超时等待，才能确保端口及时可靠释放。
System.exit() 本身不会自动释放端口，端口是否释放取决于 JVM 关闭时操作系统回收资源的时机，而这个过程不可控。真正能确保端口被及时、可靠释放的方式，是在 JVM 正常退出前，通过 ShutdownHook 主动关闭监听套接字（如 ServerSocket、Netty Channel、Tomcat Connector 等），而不是依赖 exit 后的系统自动清理。
为什么不能靠 System.exit() 自动释放端口
调用 System.exit() 会立即启动 JVM 关闭流程，但它不等于“立刻释放所有网络资源”。如果服务还在监听某个端口（比如 Spring Boot 内嵌 Tomcat 占着 8080），而你没显式关闭 Web 容器，JVM 虽然终止，但操作系统可能短暂保留该端口处于 TIME_WAIT 状态，甚至在极端情况下（如钩子未执行、kill -9 强杀）导致端口残留，下次启动时报 “Address already in use”。
正确做法：在钩子里显式关闭监听组件
关键不是“等 exit 帮你关”，而是“在 exit 触发前，自己把端口关掉”。具体操作取决于你用的是什么框架或网络库：
-
Spring Boot 应用：不要手动调用 System.exit()，改用
SpringApplication.exit(context, exitCode)，它会触发 ApplicationContext 关闭流程，自动停用内嵌容器（如 Tomcat）、释放端口；也可通过 Actuator 的/actuator/shutdown端点（需启用）实现相同效果 -
裸 Netty / Undertow / 自研 ServerSocket：注册 ShutdownHook，在其中调用
serverChannel.close()、bossGroup.shutdownGracefully()、workerGroup.shutdownGracefully()，并 await 终止完成（建议设 5 秒超时） - 使用了连接池或 RPC 框架（如 gRPC、Dubbo）：一并关闭其服务端实例，避免后台线程持续占用端口
钩子编写注意事项
一个安全有效的端口释放钩子应满足：
- 只做必要清理：专注关闭监听器、释放绑定端口，不做远程调用、文件写入等耗时或不可靠操作
- 带超时控制：例如用
shutdownGracefully().awaitUninterruptibly(5, TimeUnit.SECONDS)，防止阻塞导致进程卡住 - 加 try-catch 包裹：避免因某一步异常（如端口已关闭）导致整个钩子中断，影响其他清理逻辑
- 避免重复执行：钩子天然幂等性差，若应用多次触发 exit（比如测试中连续调用），建议加 volatile 标志位判断是否已执行过
哪些场景下钩子根本不会运行？
以下情况 端口不会被主动释放，因为 ShutdownHook 完全不触发：
- 用
kill -9 pid强制终止进程 - JVM 崩溃（如 OOM、Segmentation Fault）
- 物理断电或容器被 kill -STOP 后强制删 container
这些属于非正常退出，无法靠 Java 层逻辑兜底。生产环境应配合运维手段（如 Kubernetes preStop hook 发送 SIGTERM、设置 terminationGracePeriodSeconds）来保障有足够时间执行钩子。
