（翻译www.java-performance.com）提高Java程序性能--JDK篇（四）

标签：

java.io.ByteArrayOutputStream: java.io.ByteArrayOutputStream, java.nio.ByteBuffer: why you should not use ByteArrayOutputStream in the performance critical code.
1. 对性能要求高的代码用ByteBuffer代替ByteArrayOutputStream，如果你仍然要用ByteArrayOutputStream那么除去它的同步。
2. 如果你的函数在向一个未知的OutputStream写一些数据时，先将数据写到ByteArrayOutputStream再用ByteArrayOutputStream的writeTo(OutputStream)函数写到OutputStream中。有种极少出现的场景那就是从byte流中创建String，记得使用ByteArrayOutputStream.toString函数来实现。
3. 在部分情况下请避免使用ByteArrayOutputStream.toByteArray函数，因为它会复制一份内部byte数组。特别是当你的程序使用了几G的内存时，垃圾收集器在收集这些拷贝时会显著地花费一些时间。

java.io.BufferedInputStream and java.util.zip.GZIPInputStream: java.io.BufferedInputStream, java.util.zip.GZIPInputStream, java.nio.channels.FileChannel: some minor performance pitfalls in these two streams.
1. BufferedInputStream和GZIPInputStream都有内部缓冲区。前一个的默认大小是8K，后一个的默认大小是512B。通长它们至少增长64K。
2. 不要将BufferedInputStream作为GZIPInputStream的输入流，好的做法是在在构造GZIPInputStream时指定一个缓冲区大小。不过，保持一个BufferedInputStream仍然是安全的。
3. 如果你有这么一个对象new BufferedInputStream( new FileInputStream( file ) )，且经常调用它的available函数（比如每读取一次就要调用一两次），这时候你应该考虑覆盖(override)BufferedInputStream.available函数。这会极大提升读文件的速度。

Performance of various general compression algorithms - some of them are unbelievably fast!: java.util.zip.GZIPInputStream / GZIPOutputStream / DeflaterOutputStream / InflaterInputStream, LZ4, Snappy: checking performance of various general purpose Java compressors.
1. 如果你觉得压缩数据特别的慢，那么尝试下LZ4（快）的实现，它压缩一个文本文件速度可以达到320 Mb/sec，对大部分应用来说这个速度基本不会有明显的感觉了。如果可能的话，将LZ4的压缩缓冲大小设置到它的32M极限，这会很有用（解压也差不多）。你也可以用一个32M大小的缓冲将2个LZ4BlockOutputStream-s串起来，以获得更大的好处。
2. 如果你受限于不能使用第三方库来实现压缩，或想要好一点的压缩，尝试下JDK的deflate (lvl=1) codec，同样的文件它速度可以达到75 Mb/sec。

原文

java.io.ByteArrayOutputStream: java.io.ByteArrayOutputStream, java.nio.ByteBuffer: why you should not use ByteArrayOutputStream in the performance critical code.

Tags: Java IO, avoid it.

• For performance critical code try to use ByteBuffer instead of ByteArrayOutputStream. If you still want to use ByteArrayOutputStream - get rid of its synchronization.
• If you are working on a method which writes some sort of message to unknown OutputStream, always write your message to the ByteArrayOutputStream first and use itswriteTo(OutputStream) method after that. In some rare cases when you are building a String from its byte representation, do not forget about ByteArrayOutputStream.toStringmethods.
• In most cases avoid ByteArrayOutputStream.toByteArray method - it creates a copy of internal byte array. Garbage collecting these copies may take a noticeable time if your application is using a few gigabytes of memory (see Inefficient byte[] to String constructor article for another example).

java.io.BufferedInputStream and java.util.zip.GZIPInputStream: java.io.BufferedInputStream, java.util.zip.GZIPInputStream, java.nio.channels.FileChannel: some minor performance pitfalls in these two streams.

Tags: high throughput, CPU optimization, memory optimization, data compression.

• Both BufferedInputStream and GZIPInputStream have internal buffers. Default size for the former one is 8192 bytes and for the latter one is 512 bytes. Generally it worth increasing any of these sizes to at least 65536.
• Do not use a BufferedInputStream as an input for a GZIPInputStream, instead explicitly set GZIPInputStream buffer size in the constructor. Though, keeping a BufferedInputStreamis still safe.
• If you have a new BufferedInputStream( new FileInputStream( file ) ) object and you call its available method rather often (for example, once or twice per each input message), consider overriding BufferedInputStream.available method. It will greatly speed up file reading.

Performance of various general compression algorithms - some of them are unbelievably fast!: java.util.zip.GZIPInputStream / GZIPOutputStream / DeflaterOutputStream / InflaterInputStream, LZ4, Snappy: checking performance of various general purpose Java compressors.

Tags: high throughput, CPU optimization, storage optimization, data compression, GZIP, deflate, LZ4, Snappy.

• If you think that data compression is painfully slow, then check LZ4 (fast) implementation, which is able to compress a text file at ~320 Mb/sec - compression at such speed should be not noticeable for most of applications. It makes sense to increase the LZ4 compression buffer size up to its 32M limit if possible (keep in mind that you will need a similarly sized buffer for uncompression). You can also try chaining 2 LZ4BlockOutputStream-s with 32M buffer size to get most out of LZ4.
• If you are restricted from using 3rd party libraries or want a little bit better compression, check JDK deflate (lvl=1) codec - it was able to compress the same file at ~75 Mb/sec.

（翻译www.java-performance.com）提高Java程序性能--JDK篇（四）

标签：

原文地址：http://www.cnblogs.com/re1n/p/5921110.html