互联网上有很多关于如何使用StandardOpenOption.DELETE_ON_CLOSE的示例，例如：
Files.write(myTempFile, ..., StandardOpenOption.DELETE_ON_CLOSE);
其他示例同样使用 Files.newOutputStream(..., StandardOpenOption.DELETE_ON_CLOSE)。
我怀疑所有这些示例都可能存在缺陷。写入文件的目的是在某个时候你会读取它；否则，为什么要写它呢？但是，DELETE_ON_CLOSE是否会在你有机会读取文件之前删除文件呢？
如果您创建一个工作文件（用于处理太大而无法保存在内存中的大量数据），那么您不会使用允许读写访问的RandomAccessFile吗？但是，据我所见，RandomAccessFile没有提供指定DELETE_ON_CLOSE的选项。
那么，有人能向我展示DELETE_ON_CLOSE实际上有用吗？
Files.write(myTempFile, ..., StandardOpenOption.DELETE_ON_CLOSE) 在这个例子中使用 DELETE_ON_CLOSE 是没有意义的。在互联网上进行了（不算太强烈的）搜索后，我唯一找到的一个显示出所提到用法的例子是你可能从中获取的（http://softwarecave.org/2014/02/05/create-temporary-files-and-directories-using-java-nio2/）。Files.write(...)。API 很清楚地说明了：
抱歉我不能给您一个有意义的简短示例，但是可以将这样的文件视为操作系统使用的交换文件/分区。在当前JVM需要临时将数据存储到磁盘上，并在关闭后数据不再使用的情况下。实际的例子是类似于JEE应用程序服务器可能会决定将一些实体序列化到磁盘上以释放内存。该选项主要用于仅由 Java 虚拟机的单个实例使用的 工作文件。不建议在同时被其他实体并发打开的文件上使用此选项。
.
static final int RECORD_LENGTH = 20;
static final String RECORD_FORMAT = "%-" + RECORD_LENGTH + "s";
// add exception handling, left out only for the example
public static void main(String[] args) throws Exception {
EnumSet<StandardOpenOption> options = EnumSet.of(
StandardOpenOption.CREATE,
StandardOpenOption.WRITE,
StandardOpenOption.READ,
StandardOpenOption.DELETE_ON_CLOSE
);
Path file = Paths.get("/tmp/enternal_data.tmp");
try (SeekableByteChannel sbc = Files.newByteChannel(file, options)) {
// during your business processing the below two cases might happen
// several times in random order
// example of huge datastructure to externalize
String[] sampleData = {"some", "huge", "datastructure"};
for (int i = 0; i < sampleData.length; i++) {
byte[] buffer = String.format(RECORD_FORMAT, sampleData[i])
.getBytes();
ByteBuffer byteBuffer = ByteBuffer.wrap(buffer);
sbc.position(i * RECORD_LENGTH);
sbc.write(byteBuffer);
}
// example of processing which need the externalized data
Random random = new Random();
byte[] buffer = new byte[RECORD_LENGTH];
ByteBuffer byteBuffer = ByteBuffer.wrap(buffer);
for (int i = 0; i < 10; i++) {
sbc.position(RECORD_LENGTH * random.nextInt(sampleData.length));
sbc.read(byteBuffer);
byteBuffer.flip();
System.out.printf("loop: %d %s%n", i, new String(buffer));
}
}
}
DELETE_ON_CLOSE是用于处理临时文件的。DELETE_ON_CLOSE尝试在显式调用close()方法关闭文件时或JVM关闭之前自动删除该文件。这里有两种可能的使用方式：
此方法返回一个SeekableByteChannel，适用于读写操作，其中当前位置可以修改。
在需要将某些数据存储到内存之外以进行读/写访问且不需要在应用程序关闭后保留的情况下，似乎非常有用。
使用任意文本文件的示例：
Path p = Paths.get("C:\\test", "foo.txt");
System.out.println(Files.exists(p));
try {
Files.createFile(p);
System.out.println(Files.exists(p));
try (BufferedWriter out = Files.newBufferedWriter(p, Charset.defaultCharset(), StandardOpenOption.DELETE_ON_CLOSE)) {
out.append("Hello, World!");
out.flush();
try (BufferedReader in = Files.newBufferedReader(p, Charset.defaultCharset())) {
String line;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
}
}
} catch (IOException ex) {
ex.printStackTrace();
}
System.out.println(Files.exists(p));
false
true
Hello, World!
false
File.deleteOnExit方法可能更可取，因为您不需要在文件的任何读操作期间保持输出流处于打开状态。newByteChannel的解决方案。第二个选项，使用newBufferedReader，在Windows上可以工作，但我不确定它是否适用于Linux。今晚回家后我会检查一下。你看，在Linux上，当你指定DELETE_ON_CLOSE时，文件是打开并删除的，因此在文件系统中没有指向该文件的目录条目，因此调用newBufferedReader可能无法从指定路径找到该文件，即使该文件仍然存在。 - Klitos Kyriacou
DELETE_ON_CLOSE而不是旧的File.deleteOnExit方法，但它们并不相同！ - daiscogFile.deleteOnExit已被“在createFile方法中指定的DELETE_ON_CLOSE选项所取代。”这是完全错误的。createFile方法并不接受DELETE_ON_CLOSE参数。 - Klitos KyriacouFile.deleteOnExit方法在新的java.nio.fileAPI中实际上没有合适的替代方法，这意味着在某些情况下转移到新的API是不可能的。 - daiscog