我认为，如果不对软件进行基准测试，您将无法得到严格的答案。在适当的条件下，NIO可能会大大加快应用程序的速度，但同时也会使事情变慢。以下是一些要点：
- 您真的需要琴弦吗？如果您从数据库存储和接收字节，则可以避免字符串分配和编码成本的总和。
- 你真的需要
rewind
和flip
？似乎您正在为每个字符串创建一个新缓冲区，然后将其写入通道。（如果您采用NIO方式，则可以重用缓冲区而不是包装/丢弃的基准策略，我认为它们会做得更好）。 - 请记住，
wrap
和allocateDirect可能会产生完全不同的缓冲区。两者都要进行基准测试，以权衡取舍。对于直接分配，请确保重用相同的缓冲区，以实现最佳性能。 - 最重要的是：确保将NIO与BufferedOutputStream和/或BufferedWritter方法进行比较（也使用大小合适的中间件
byte[]
或char[]
缓冲区）。我见过很多，很多，很多人发现，NIO没有银弹。
如果您喜欢某些前沿技术，请返回IO
Trails以获取一些NIO2：D。
这是有关使用不同策略进行文件复制的有趣基准。我知道这是一个不同的问题，但是我认为大多数事实和作者结论也适用于您的问题。
干杯，
更新1：
由于@EJP提示我直接缓冲区对于解决此问题并不有效，因此我自己对其进行了基准测试，并最终使用内存映射文件开发了一个不错的NIO解决方案。在运行OS X
Lion的Macbook中，这一点可观
BufferedOutputStream。但请记住，这可能是特定于OS /硬件/ VM的：
public void writeToFileNIOWay2(File file) throws IOException { final int numberOfIterations = 1000000; final String messageToWrite = "This is a test üüüüüüööööö"; final byte[] messageBytes = messageToWrite. getBytes(Charset.forName("ISO-8859-1")); final long appendSize = numberOfIterations * messageBytes.length; final RandomAccessFile raf = new RandomAccessFile(file, "rw"); raf.seek(raf.length()); final FileChannel fc = raf.getChannel(); final MappedByteBuffer mbf = fc.map(FileChannel.MapMode.READ_WRITE, fc. position(), appendSize); fc.close(); for (int i = 1; i < numberOfIterations; i++) { mbf.put(messageBytes); }}我承认我通过预先计算要添加的总大小（大约26
MB）而有所作弊。对于某些实际情况，这可能是不可能的。不过，您始终可以为操作使用“足够大的附加大小”，并在以后截断文件。
更新2（2019）：
对于任何寻求现代（如Java
11+）解决方案的人，我将遵循@DodgyCodeException的建议并使用
java.nio.file.Files.writeString：
String fileName = "/xyz/test.txt";String messageToWrite = "My long string";Files.writeString(Paths.get(fileName), messageToWrite, StandardCharsets.ISO_8859_1);
