system类不能防止句柄泄漏，因其不参与线程状态控制或资源释放；句柄泄漏源于线程未显式关闭文件、socket、graphics等本地资源，需靠try-with-resources、中断响应和finally清理来防护。
System类本身不提供防止句柄泄漏的功能，也不能直接用于控制线程状态或资源释放。所谓“用System类防止长周期RUNNABLE线程发生句柄泄漏”是一个常见误解——System类（如System.gc()、System.exit()等）与线程生命周期管理、句柄资源回收没有直接关系。句柄泄漏（如文件描述符、Socket、Graphics对象、JNI全局引用等）的根本原因在于：线程长期运行且未显式释放本地资源，而非线程处于RUNNABLE状态本身。
理解句柄泄漏的真实来源
Java中“句柄”通常指操作系统级资源（如Linux的fd、Windows的HANDLE），它们由JVM通过底层系统调用申请，但不会被GC自动回收。常见泄漏场景包括：
- 线程中打开FileInputStream/Socket/ServerSocket后未在finally或try-with-resources中关闭
- 使用AWT/Swing创建Graphics、Font或Image后未dispose()
- 通过JNI获取了全局引用（GlobalRef）但未DeleteGlobalRef
- 使用NIO的DirectByteBuffer时，背后映射的native内存未被及时释放（尤其配合MappedByteBuffer或自定义Cleaner）
真正有效的防护手段
防范关键不在System类，而在资源生命周期管理和线程退出机制：
- 强制资源封装：所有可关闭资源必须用try-with-resources包裹，确保即使异常也能释放
- 线程退出时清理钩子：在长周期线程主循环中检测中断信号，并在break前执行close()、dispose()、Cleaner.clean()等
- 避免静态持有资源：不要将FileChannel、Socket等存为static字段，防止被长期持有可能导致泄漏
-
监控与诊断：用lsof -p
（Linux）或Process Explorer（Windows）观察fd/handle增长；结合jstack确认线程是否卡死在I/O或阻塞点
System类能做什么？——及其局限性
System类中的某些方法常被误用，需明确其实际作用：
- System.gc()：仅建议JVM执行GC，不保证触发，且对本地句柄零影响
- System.runFinalization()：已废弃，不推荐使用；finalize机制本身不可靠且已被标记为deprecated
- System.exit()：强制终止JVM，会触发Shutdown Hook，可用于最后兜底清理，但属于非常规手段，不能作为日常防护
推荐实践示例（线程内安全释放）
以下是一个典型长周期网络监听线程的安全写法：
Thread worker = new Thread(() -> {
ServerSocket server = null;
try {
server = new ServerSocket(8080);
while (!Thread.currentThread().isInterrupted()) {
Socket client = server.accept(); // 可被interrupt打断
handleClient(client);
}
} catch (IOException e) {
if (!Thread.currentThread().isInterrupted()) {
log.error("I/O error", e);
}
} finally {
if (server != null && !server.isClosed()) {
try { server.close(); } catch (IOException ignored) {}
}
}
});
worker.start();
注意：accept()支持中断，close()会唤醒阻塞线程；资源释放放在finally中，不受循环或异常影响。
