复制时，commons-io使用本地缓冲区：
http://svn.apache.org/viewvc/commons/proper/io/trunk/src/main/java/org/apache/commons/io/CopyUtils.java?view=markup （搜索DEFAULT_BUFFER_SIZE）
虽然Eclipse使用静态同步缓冲区来阻止并发复制操作： http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.core.resources/src/org/eclipse/core/internal/utils/FileUtil.java?view=markup （搜索缓冲区）
静态缓冲区似乎可以在顺序处理小文件时提高性能，但会降低并行副本的性能。
eclipse静态同步缓冲区是否具有真实的性能改进，或者只是过度工程化？
在这种情况下，您建议使用什么？
答案 0 :(得分：2)
它确实没有显着的性能差异，静态缓冲区通常是一个非常糟糕的主意，除非你知道你是线程安全的。他们这样做了（如果你看一下评论）因为他们理解更高级别对象的同步。
所以总是只分配一个动态缓冲区。
答案 1 :(得分：0)
我更喜欢commons-io方法：更容易阅读，性能可能非常相似。
成本是commons-io将在每次copy（）调用时创建一个新字节[8192]。但要记住两件事：
新字节[8192]在大多数系统上几乎是瞬时的。这不是一个昂贵的构造函数！
在大多数情况下，InputStream.read（）通常都很慢！ （例如文件阅读或插座阅读！）
因此，与实际流复制相比，对新字节[8192]的调用将非常快。 Eclipse优化（在这个特定的例子中）是一个虚假的经济（它不是瓶颈！），导致更复杂，更难理解的代码。
答案 2 :(得分：0)
如果您担心性能，我会使用直接的ByteBuffers。这种缓冲是最好的，但是NIO（2004年以来可用）速度更快恕我直言。 （高达30％）
否则，分配成本非常小（除非您试图避免使用GC）