exit状态码仅标识进程终止结果，不释放句柄；真正释放依赖内核资源回收，但须进程正常退出。使用_exit()、SIGKILL或主线程return均会跳过清理链路，导致句柄未安全释放；应主动调用SQLFreeHandle、close等确保安全。
exit状态码本身不负责释放句柄连接，它只是进程终止的“信号”和“结果标识”。真正完成句柄释放的是内核在进程终止流程中执行的资源回收动作——前提是进程以**正常、可控的方式退出**，而非被强制杀死。安全释放未完结的句柄（如文件描述符、ODBC语句句柄、网络socket等），关键在于让exit触发完整的清理链路，而不是跳过用户态或内核态的释放步骤。
确保exit走完整清理路径，而非绕过
很多句柄无法安全释放，是因为调用了跳过清理的退出方式：
- 用_exit()或syscall(SYS_exit)直接进内核：跳过C库的缓冲区刷新、atexit注册函数执行、stdio流关闭等，可能导致文件句柄虽被内核回收，但数据丢失或数据库连接未发送FIN包；
- 被SIGKILL强制终止：内核立即回收资源，不通知用户态，所有注册的清理函数（如ODBC SQLFreeHandle、fclose、close）完全不执行；
- 主线程return但未调用exit()：若程序使用pthread且存在其他线程，return仅结束主线程，进程未终止，句柄持续占用。
在退出前显式释放关键句柄
依赖exit自动回收是被动策略；主动释放才是安全底线。尤其对ODBC、数据库连接、网络套接字等长生命周期句柄：
- 在调用exit()前，手动调用SQLFreeHandle(SQL_HANDLE_STMT)、close(fd)、shutdown(sock, SHUT_RDWR)等；
- atexit()注册清理函数，确保即使从任意位置调用exit()也能触发释放逻辑；
- TerminateProcess()会跳过DLL_PROCESS_DETACH通知，应优先用ExitProcess()。
配合退出状态码做错误归因与重试判断
状态码不释放资源，但能帮你定位为何句柄没被释放：
- exit(0)：常规退出，可假设清理函数已运行（需验证是否真被调用）；
- exit(1)或更高：表示异常路径退出，应检查对应分支是否遗漏了句柄释放代码；
- 脚本中用$?捕获状态，非0时触发日志审计或告警，例如记录“ODBC连接未调用SQLFreeHandle即退出”。
系统级兜底：避免句柄泄漏积累
单次exit处理得当还不够，长期运行的服务更要防累积泄漏：
- Linux下用lsof -p PID或/proc/PID/fd/定期检查残留句柄；
- Windows下用handle.exe -p PID或资源监视器确认句柄类型（EVENT、FILE、ALPC_PORT等）；
- ODBC应用启用SQL_ATTR_CONNECTION_TIMEOUT和连接池超时，避免挂起句柄长期不释放。
