java临时目录由java.io.tmpdir系统属性指定，linux/macos默认为/tmp，windows为c:\users\{user}\appdata\local\temp，运行时通过system.getproperty("java.io.tmpdir")获取，不可运行时修改，需在jvm启动时用-djava.io.tmpdir=设置，且应验证可写性并使用createtempfile()等标准api。
Java临时目录在哪？java.io.tmpdir 默认值怎么查
它不是固定路径，而是 JVM 启动时从操作系统继承的环境变量，不同系统默认值不同：/tmp（Linux/macOS）、C:\Users\{user}\AppData\Local\Temp（Windows）。直接打印 System.getProperty("java.io.tmpdir") 就能确认当前值，别猜，也别硬编码路径。
常见错误现象：本地跑得好好的，部署到 Docker 或某些容器平台后，File.createTempFile() 报 IOException: Permission denied 或写入失败——大概率是容器里 /tmp 不可写，或被挂载为只读。
- 运行时检查比编译时假设更可靠：每次用前先
new File(System.getProperty("java.io.tmpdir")).canWrite()简单验证下 - 不要在代码里拼接
"tmp/" + filename，必须用File.createTempFile()或Files.createTempDirectory()，它们会自动适配java.io.tmpdir - Docker 场景下，如果改不了镜像权限，最简方案是启动容器时加参数：
-e JAVA_TOOL_OPTIONS="-Djava.io.tmpdir=/app/tmp"，并确保/app/tmp目录存在且可写
怎么安全地修改 java.io.tmpdir 的值
不能通过 System.setProperty() 运行时修改——JVM 初始化后该属性就冻结了，后续调用 createTempFile() 仍会读取原始值。唯一有效方式是在 JVM 启动阶段注入。
使用场景集中在：容器部署、多租户隔离、审计要求临时文件落指定磁盘分区等。
立即学习“Java免费学习笔记（深入）”；
- 命令行启动：加
-Djava.io.tmpdir=/path/to/your/tmp，注意路径末尾不加斜杠，且 JVM 必须有读写权限 - Spring Boot：在
application.properties里写JAVA_OPTS=-Djava.io.tmpdir=/data/tmp不生效；正确做法是设环境变量JAVA_TOOL_OPTIONS=-Djava.io.tmpdir=/data/tmp（JVM 自动识别）或改启动脚本里的java命令参数 - Tomcat：在
bin/setenv.sh（Linux）或setenv.bat（Windows）中添加export JAVA_OPTS="$JAVA_OPTS -Djava.io.tmpdir=/opt/tomcat/temp"
java.io.tmpdir 改了但 File.createTempFile() 还是写错地方？
不是配置没生效，是方法用错了。这个方法内部会读取 java.io.tmpdir，但如果你传了 File 类型的 dir 参数，它就完全忽略系统属性，直接往你指定的目录里写。
典型错误示例：File.createTempFile("log", ".txt", new File("/wrong/path")) —— 这时 java.io.tmpdir 设成啥都没用。
- 想走系统临时目录，就只传前两个参数：
File.createTempFile("prefix", ".suffix") - 如果必须指定目录，别绕过
java.io.tmpdir，而是先确保该目录符合预期：比如new File(System.getProperty("java.io.tmpdir"), "subdir")，再传进去 - Java 7+ 推荐用
Files.createTempFile(Path.of(System.getProperty("java.io.tmpdir")), "prefix", ".suffix")，类型安全，路径处理更稳
临时目录路径变更对性能和清理有什么影响
路径本身不影响 JVM 性能，但位置选得不好会拖慢 I/O 或引发清理问题。比如把临时目录设在 NFS 挂载点上，createTempFile() 可能变慢甚至超时；设在内存盘（如 /dev/shm）虽快，但重启就丢，且不自动清理。
关键点在于：JVM 不负责清理临时文件，deleteOnExit() 在进程异常退出时大概率失效，别依赖它。
- 生产环境务必配合外部清理机制：Linux 上用
tmpwatch或systemd-tmpfiles，K8s 里用 initContainer 定期find /tmp -name "*.tmp" -mmin +60 -delete - 避免跨设备迁移：比如从
/tmp改到/home/app/tmp，如果/home是单独挂载的慢盘，大文件临时操作会卡住 - Java 11+ 新增
Files.createTempDirectory()返回的Path支持register()监听删除事件，适合需要精细控制生命周期的场景
最容易被忽略的是：很多框架（Logback、Spring Boot Actuator）内部也用 java.io.tmpdir，改了 JVM 属性后，得同步检查这些组件是否真用了新路径，而不是自己缓存了旧值。
