根本原因是WSL2通过9P协议挂载/mnt/c导致频繁上下文切换和协议翻译；Java应将工作目录、日志等全移至/home或/tmp，并配置-Djava.io.tmpdir=/tmp、日志路径及配置文件路径均指向WSL2本地路径。
WSL2里Java读写Windows文件慢得明显，根本原因是什么
不是Java的问题，是WSL2的跨文件系统访问机制导致的——/mnt/c 下的路径本质是通过9P协议挂载的网络文件系统，每次FileInputStream.read()或Files.lines()都会触发用户态到内核态的多次上下文切换和协议翻译。实测小文件随机读取延迟比Linux原生路径高5–10倍，大文件顺序读写吞吐量通常只有原生的30%–60%。
Java应用该把数据放哪才能避开/mnt/c性能陷阱
必须把Java工作目录、日志、临时文件、配置文件等全部挪到WSL2自己的文件系统里（即/home/username/或/tmp），而不是/mnt/c/Users/xxx/。Windows端编辑器（如VS Code）可以继续用Remote-WSL插件打开/home下的项目，不影响开发体验。
- 启动脚本里显式指定
-Djava.io.tmpdir=/tmp，避免System.getProperty("java.io.tmpdir")默认落到/mnt/c - Logback或Log4j的
file路径别写C:\logs\app.log，改用/home/user/logs/app.log - Spring Boot的
spring.config.location若指向file:C:/config/，同样要改成file:/home/user/config/ - IDE运行配置中检查
Working directory是否仍设为C:\project，应改为/home/user/project
真要读写Windows文件怎么办：绕过9P，走网络或共享
如果业务逻辑强制要求读取C:\data\input.csv这类路径（比如客户只给Windows路径），硬读/mnt/c/data/input.csv就是慢。此时更优解是让Windows提供服务化访问：
- 在Windows开一个轻量HTTP服务（比如Python
python -m http.server 8000），Java用HttpURLConnection或WebClient拉取，避免文件系统层瓶颈 - 用Windows自带的SMB共享（启用“网络发现”和“文件共享”），在WSL2里
mount -t cifs //HOSTNAME/share /mnt/share -o user=xxx，虽然仍有开销，但比9P稳定且可控 - 彻底规避：用
wsl --export和--import定期同步数据，Java只操作本地路径，同步动作由Windows定时任务触发
验证是否真的改善了：看这三个指标
别只看应用启动时间，重点盯住I/O行为本身：
立即学习“Java免费学习笔记（深入）”；
- 用
iotop -P -p $(pgrep -f 'java.*YourApp')确认Java进程的IO WAIT%是否从>40%降到 - 在Java代码里加
System.nanoTime()打点，对比Files.size(Paths.get("/mnt/c/..."))和Files.size(Paths.get("/home/..."))耗时差异 - 用
cat /proc/mounts | grep 9p确认你正在读写的路径是否还落在9P挂载点上（输出含9p即未规避）
跨系统路径的性能损耗藏在底层协议里，不迁出/mnt/c就永远在和9P博弈。很多人调了JVM参数、换了IO库，结果发现只是在给慢车道装涡轮增压。
