我正在编写一个加密文件的加密程序。
我希望加密的内容将替换原始内容，以便恢复程序无法恢复它（即，使用与原始内容相同的内存地址）。
假设加密内容的大小与原始内容的大小相同。
我想File.renameTo()不会这样做，因为它是独立于平台的，所以它有点不可预测。
请原谅我没有发布我的完整代码（呃！），但我使用Buffered Input/OutputStream来读取/写入数据。
在某些情况下（在某些操作系统上，在某些文件系统上，在某些文件系统上，带有一些挂载选项），RandomAccessFile将允许您执行该执行的操作。还要考虑如何将敏感数据排除在 Java 堆之外......例如，避免将String用作从未加密文件构造的对象的一部分，并在以后写入加密文件。但是，在其他情况下，您的建议根本不可能。正如 GNU shred 手册页所述，
注意：请注意，切碎依赖于一个非常重要的假设：即 文件系统将就地覆盖数据。 这是传统方式 做事，但许多现代文件系统设计不能满足这一点 假设。 以下是切碎的文件系统示例 无效，或者不能保证在所有文件系统模式下都有效：
- 日志结构或日志文件系统，例如随附的文件系统 AIX 和 Solaris（以及 JFS、ReiserFS、XFS、Ext3 等）
- 写入冗余数据并继续运行的文件系统，即使有些 写入失败，例如基于 RAID 的文件系统
- 创建快照的文件系统，例如网络设备的 NFS 服务器
- 缓存在临时位置的文件系统，例如 NFS 版本 3 客户
- 压缩文件系统