log4j是否使用NIO将数据写入文件？
它似乎已经相当快了，我只是想知道是否有人知道它是否使用 NIO。我尝试搜索 NIO 的整个源代码（嗯，这是一种搜索方式：）哈哈）；但没有击中任何东西。另外，如果它不使用NIO；您认为是否值得修改 log4j 以使用 NIO 来使其更快？任何指示建议和一些资源的链接都会很有帮助。
It seems to be pretty fast already and i was just wondering if anyone knows if its using NIO. I tried searching the whole source code for NIO (well, its kind of way to search :) lol); but did not hit anything. Also, If its not using NIO; do you think its worthwhile to modify log4j to use NIO also to make it more faster? Any pointers advises and links to some resources would be lot helpful.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不可以，除非日志记录是应用程序活动的重要组成部分，在这种情况下通常会出现问题。
您似乎认为蔚来“更快”，但总体而言并非如此。只需尝试创建两个文件，一个使用标准 IO，另一个使用 NIO，向其中写入一堆数据并关闭它们。您会发现性能几乎没有什么不同。 NIO只会在某些用例中表现更好；最常见的是许多连接的情况。
No, unless logging is a significant part of your application's activities, in which case there is usually something wrong.
You seem to be under the impression that NIO 'is faster', but this is not true in general. Just try creating two files, one with standard IO and one with NIO, writing a bunch of data to them and closing them. You'll see the performance hardly differs. NIO will only perform better in certain use cases; most usually the case of many connections.
查看 FileAppender 源。几乎只是标准的
java.io。Check out the FileAppender source. Pretty much just standard
java.io.在这种情况下，我看不出 FileChannel 比 FileOutputStream 更快的任何原因。
也许通过使用MappedByteBuffer？但在追加模式下，行为取决于操作系统。
最终，性能取决于您的硬盘驱动器，您的代码无关紧要。
I don't see any reason why FileChannel could be any faster than FileOutputStream in this case.
maybe by using MappedByteBuffer? but in append mode, the behavior is OS dependent.
ultimately, the performance depends on your hard drive, your code matters very little.
详细阐述 Confusion 的答案，File NIO 也会阻塞。这就是为什么它在某些场景中并不比传统文件IO更快。引用 O'Reilly 的 Java NIO 书：
编辑：话虽如此，如果将 File NIO 与 MappedByteBuffer 一起使用，您可以获得更好的读/写效率。请注意，在 Log4j 2 中使用 MappedByteBuffer 正在考虑中。
Elaborating on Confusion's answer, File NIO blocks as well. That's why it is not faster than traditional File IO in some scenarios. Quoting O'Reilly's Java NIO book:
Edit: With that said, you can get better read/write efficiency if you use File NIO with a MappedByteBuffer. Note that using MappedByteBuffer in Log4j 2 is under consideration.