FileOutputStream 本身不提供线程安全或进程互斥能力，多线程或多进程直接写同一文件易导致覆盖或错乱；解决核心是避免并发写同一句柄、强制串行化或改用安全协作方式。
Java 中 FileOutputStream 本身**不提供线程安全或进程间互斥能力**，直接多线程/多进程往同一个文件写，尤其用默认构造（append = false）时，极易覆盖或错乱。这不是 bug，而是设计使然——它只负责“打开并写”，不负责协调。解决的核心思路是：**避免并发写同一文件句柄，或强制串行化访问，或改用更安全的协作方式。**
明确区分：单 JVM 多线程 vs 跨 JVM 进程
这是两类完全不同问题，解法也不同：
-
同一 JVM 内多个线程写同一个 FileOutputStream 实例：绝对禁止。
FileOutputStream非线程安全，write() 可能交错、丢字节、覆盖缓冲区。 -
不同 JVM 进程（或不同程序）同时写同一文件路径：操作系统层面不保证原子性。即使加了 NIO 文件锁（
FileLock），它只是建议性锁（advisory），FileOutputStream构造时仍会清空文件——锁拦不住“打开即覆盖”这个动作。
推荐方案：用追加模式 + 同步控制
如果必须让多个线程往一个日志类文件持续写入，最实用做法是：
- 所有线程共用**同一个
FileOutputStream实例**（不能各自 new），且构造时指定append = true； - 对该流的
write()和flush()操作做**同步保护**（如用synchronized(fos)或ReentrantLock）； - 确保每次写完调用
flush()，避免缓冲区滞留； - 避免在写过程中关闭流——由统一管理者控制生命周期。
更健壮的替代方案：用 BufferedOutputStream + 日志框架或队列
生产环境强烈建议绕过裸流操作：
立即学习“Java免费学习笔记（深入）”；
- 使用
java.util.logging、Log4j 或 SLF4J + Logback，它们内置线程安全写入、滚动策略和异步缓冲； - 自己实现时，可用
BlockingQueue<String>收集日志，单个消费者线程从队列取数据、批量写入（带 flush），彻底规避并发冲突； - 若需高性能，考虑内存映射（
MappedByteBuffer）配合FileChannel和显式 position 控制，但复杂度高，仅限特定场景。
跨进程写同一文件？别硬刚，换思路
NIO 的 FileLock 在 Linux/Windows 上对“阻止覆盖”基本无效——因为 new FileOutputStream(file) 会 truncate 文件，此时锁还没拿到。真正可行的做法是：
-
用唯一临时文件名写入，再原子重命名（
Files.move(temp, target, StandardCopyOption.REPLACE_EXISTING)），Linux 下 rename 是原子的； - 引入中心协调者，比如用 Redis 分布式锁，或通过文件系统级信号量（如创建 lock 文件 + try-with-resources 检查）；
- 根本回避共享写入：每个进程写独立文件（如按 PID 或时间戳命名），后续由归档服务合并。
