Android AtomicFile的适用场景及读写使用问题咨询

先明确两个基础结论：

• AtomicFile 从设计上就不提供线程安全保障，如果存在多线程并发读写同一个目标文件的场景，必须由业务层在外层自行加互斥锁做同步，它从始至终都不是用来解决并发访问冲突问题的。
• 它的核心价值，确实是应对写入过程中突发应用崩溃、设备掉电、进程被系统强制杀死这类非预期异常，避免生成半写入的无效损坏文件。实现逻辑非常朴素：所有写入操作不会直接改动目标原文件，而是先写到同目录下的临时文件里，等全部内容写完、执行fsync强制刷盘确保数据真正落到存储介质后，再通过文件系统自带原子性的重命名操作，用临时文件替换正式原文件。只要没走到最后重命名这一步，不管中途出什么异常，原文件都会保持上一次写入完成后的完整状态，不会被损坏。

至于为什么要用AtomicFile配套的读方法，而不是自己直接读目标文件，核心是它的读逻辑和异常恢复机制是绑定的：

• 读操作启动时会先检查是否存在上次写入异常残留的临时文件，如果检测到残留，就说明上一次写入中途被打断、没完成最终替换，会直接删掉这些无效的临时文件，从根源上避免读到半写入的垃圾数据
• 确认异常残留清理完成后，才会打开正式的原文件返回读取流，整个状态校验逻辑和写入流程完全对齐
• 如果弃用它的读方法、直接自行读取目标文件路径，你根本感知不到上次写入是否出了异常、有没有残留无效临时文件，甚至可能误把没写完的临时文件当有效数据读取，用AtomicFile防损坏的初衷就完全达不到了。

内容的提问来源于stack exchange，提问作者Steve M