概述

---

我从事的产品，是面向行业的Android应用，同时硬件也是自己开发的。因为属于工程产品以及一些因素，并没有设计电池，因此这里就一个很大的问题，掉电可能会导致数据丢失、甚至文件系统的损坏。好在，大部分场合不容易出现掉电的情况。 但有一天，同事报告一个BUG：使用PC软件配置好硬件后，拔掉电源重新上电后，硬件会自动恢复到配置之前的状态，但是拔掉电源之前，硬件提示写入配置成功。我亲自测试了一下，确实如此。操作迅速的话，基本是100%重现的。

分析

---

如果提示写入配置成功，那么说明调用文件读写API成功，数据已经在存储器上，掉电是不会丢失的，可是却出现了数据丢失的现象。通过 adb 查看文件，配置数据确实没有写入。 稍微思考一下，如果提示写入配置成功，那么也就是调用文件API成功，review下源码，是个很简单：FileOutputStream 调用，也有调用 close 方法和做异常处理。 既然代码没什么问题，那么只能从系统层面去思考了，我们知道，UNIX/LINUX内核设有缓冲区高速缓存或页面高速缓存，当写入文件的时候，先写入到高速缓存，等到适合的时机才写入到存储器上。也就是说，如果数据在缓存里面，这个时候掉电，数据就理所当然的丢失了。

解决

---

要验证这个猜想比较简单，通过API把数据从缓存刷到存储器上，然后再提示给用户。对于C语言，linux提供了：sync/fsync/fdatasync，来实现。对于Java，只能先看看FileOutputStream有什么方法可以使用。一眼看过去，比较接近的方法就是：flush了。但是，文档上 OutputStream.html#flush 是这样描述的：

Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination. If the intended destination of this stream is an abstraction provided by the underlying operating system, for example a file, then flushing the stream guarantees only that bytes previously written to the stream are passed to the operating system for writing; it does not guarantee that they are actually written to a physical device such as a disk drive. The flush method of OutputStream does nothing.

主要是后面两段，也就是说如果是一个文件，flush并不保证把数据刷到物理设备上，通常flush不做任何操作。阅读Android上的实现：FileOutputStream.java 也可以证实这点，FileOutputStream 并没有重载flush。 但是，我们注意到了 FileOutputStream 有个方法：getFD()，返回：FileDescriptor，一看名字，如果熟悉C，就知道这玩意就是文件描述符，有文件描述符，基本可以解决问题了，查看 FileDescriptor 对象，有个 sync方法，描述：

Force all system buffers to synchronize with the underlying device.

把系统缓冲区同步到基础设备，查看其源码实现 FileDescriptor.java： /** * Ensures that data which is buffered within the underlying implementation * is written out to the appropriate device before returning. */ public void sync() throws SyncFailedException { try { if (Libcore.os.isatty(this)) { Libcore.os.tcdrain(this); } else { Libcore.os.fsync(this); } } catch (ErrnoException errnoException) { SyncFailedException sfe = new SyncFailedException(errnoException.getMessage()); sfe.initCause(errnoException); throw sfe; } } 源码实现很简单， 如果打开的文件是个TTY，那么调用tcdrain，否则调用fsync。 最后，在close之前，调用fsync，然后进行测试，BUG得到了修复。

题外话

高速缓存与mount

---

当使用mount命令来挂在设备的使用，可以指定不使用或者使用缓存，该参数分别是：sync 和 async。但是对于早期的嵌入式存储设备，因为性能低，因此默认情况下都是开启缓存的。

易掉电的产品

---

我们的产品没有设计电池，因为用户数据不是很关键，加上数据是存储在云端的，就没所谓了。实际上大家非常了解的Android电视盒子或者电视，通常没有电池的（有内置RTC电池，保证断电后，时钟继续走），拔掉电源就等于关机了。 对于Android这类频繁IO的操作系统来说，直接拔掉电源风险不是一般的大，不过厂商也有不少的应对方案，即使是系统文件因为意外掉电而损坏，基本上也是能自动修复的。