File.createTempFile() 创建的临时文件默认位于 JVM 的 java.io.tmpdir 目录（可被 -Djava.io.tmpdir 覆盖），而非操作系统标准临时目录；它不自动清理，deleteOnExit() 仅在 JVM 正常退出时生效且有内存泄漏风险；推荐用 Files.createTempFile() 配合 try-finally 或 try-with-resources 显式立即删除。
File.createTempFile() 生成的文件默认不在系统目录下
调用 File.createTempFile() 创建的临时文件，实际路径由 JVM 的 java.io.tmpdir 系统属性决定，不是操作系统级的“系统目录”（如 /tmp、C:\Windows\Temp），而是该属性指向的目录——通常与系统临时目录一致，但可被启动参数覆盖（如 -Djava.io.tmpdir=/my/custom/tmp）。所以“在系统目录下”这个说法容易误解：它不保证写入 OS 的标准临时位置，只保证写入 JVM 认为的临时目录。
关键点：File.createTempFile() 本身**不负责自动清理**，它只创建文件并返回 File 对象；所谓“自动清理”需额外配合 deleteOnExit() 或显式管理生命周期。
deleteOnExit() 只在 JVM 正常退出时生效
deleteOnExit() 是最常用的“自动清理”手段，但它有严重限制：
- 仅对 JVM 正常终止（如
System.exit(0)、main 方法自然结束）有效；JVM 崩溃、kill -9、断电等场景下完全不触发 - 文件必须在 JVM 启动后、调用
deleteOnExit()前已存在，否则静默失败 - 不能跨 JVM 实例清理，重启后残留文件不会被清除
- 大量调用可能导致 JVM 内存泄漏（内部使用静态 List 缓存待删文件路径）
示例正确用法：
File tmp = File.createTempFile("prefix", ".txt");
tmp.deleteOnExit(); // 必须在 create 之后、JVM 退出前调用
// 后续可正常读写 tmp
更可靠的清理方式：try-with-resources + Files.deleteIfExists()
如果临时文件仅用于单次操作（如上传中转、解压缓存），推荐显式控制生命周期，避免依赖 JVM 钩子。Java 7+ 的 Files API 更安全：
- 用
Files.createTempFile()替代File.createTempFile()，返回Path，语义更清晰 - 配合 try-with-resources（若封装成 AutoCloseable 资源）或 finally 块，在业务逻辑结束后立即删除
- 使用
Files.deleteIfExists(path)安全删除，不抛异常
简单示例：
Path tmp = Files.createTempFile("data", ".bin");
try {
// 使用 tmp 进行 I/O 操作
Files.write(tmp, "hello".getBytes());
} finally {
Files.deleteIfExists(tmp); // 立即清理，不依赖 JVM 生命周期
}
需要跨进程/长期存活的临时文件？别用 deleteOnExit()
如果临时文件需被其他进程读取、或处理时间可能超过 JVM 生命周期（如后台任务异步处理），deleteOnExit() 完全失效。此时应：
- 明确指定临时目录（如
Paths.get(System.getProperty("java.io.tmpdir"))），避免依赖不确定路径 - 为文件名加入时间戳或 UUID，防止冲突
- 设置定期清理策略：例如启动时扫描
java.io.tmpdir下过期（如 24 小时未访问）的临时文件 - 避免在 Windows 上锁定文件导致无法删除（确保流已关闭、句柄释放）
真正棘手的是：JVM 不提供“进程退出时强制清理所有子进程创建的临时文件”的机制。跨进程协作时，清理责任必须由业务层显式承担。
临时文件的“自动清理”从来不是开箱即用的功能，它取决于你如何定义“自动”——是 JVM 退出时、方法执行完后、还是业务逻辑完成时。选错时机，文件就留在磁盘上等着填满空间。
