Complete transformation Flow, part 2nd: Optimizing Java internal I/O

Although the new Java I/O framework (Java.nio) solves most of the performance problems with I/O support, it does not meet all the performance requirements for internal communication using byte arrays and pipelines. This article is the last in a two-part series, with Java cryptography expert and author Merlin Hughes developing a new set of streams to complement standard Java I/o byte array stream classes and pipe flow classes, emphasizing high performance in the design. Please go to the discussion forum on this article to share your views on this article with the author and other readers. (You can also click on the discussion at the top or bottom of the article.) ）

In the first article in this series, you learned some different ways to solve problems that read data from sources that can only write data. In a possible solution, we studied how to use byte array streams, pipe flows, and custom frameworks that deal directly with the problem. The customization approach is clearly the most efficient solution, but the analysis of several other methods helps to see some of the problems with standard Java streams. Specifically, the byte array output stream does not provide an efficient mechanism to provide read-only access to its content, and the performance of the pipeline flow is usually poor.

To address these issues, we will implement an equally complete replacement class in this article, but more emphasis on performance when implemented. Let's start with a brief discussion of the synchronization problem, as it relates to I/O flow.

Sync problem

In general, I recommend avoiding unnecessary use of synchronization without the need for synchronization in particular. Obviously, if multiple threads need to access a class concurrently, then this class needs to be secure for the thread. However, in many cases, concurrent access is not required, and synchronization becomes an unnecessary overhead. For example, concurrent access to a convection is naturally indeterminate-you cannot predict which data is written first, or which thread reads what data-that is, in most cases, concurrent access to the convection is useless. Therefore, enforcing synchronization for all streams is a cost that does not provide the actual benefits. If an application requires thread safety, it is possible to enforce thread safety through the application's own synchronization primitives.

In fact, the API for the Collection class makes the same choice: By default, set, list, and so on are not thread-safe. If an application wants to use thread-safe Collection, it can use the collections class to create a thread-safe wrapper to wrap a thread-safe Collection. If this is useful, the application can wrap the stream in exactly the same mechanism to make it thread-safe, for example, outputstream out = Streams.synchronizedoutputstream (ByteStream). See the Streams class in the accompanying source code, which is an example of an implementation.

So, for classes I think are not available to multiple concurrent threads, I don't use synchronization to provide thread safety for these classes. Before you use this approach extensively, I recommend that you look at the Threads and locks chapter of the Java language Specification (see Resources) to understand the potential pitfalls; Specifically, the Language specification. It is not possible to ensure the order of reading and writing without using synchronization, so concurrent access to read-only methods with different steps can cause unexpected behavior, although such access may seem harmless.

Better byte array output stream

When you need to dump an unknown amount of data into a memory buffer, the Bytearrayoutputstream class is a very good stream to use. I often use this class when I store some data for later reading. However, using the Tobytearray () method to gain read access to the resulting data is inefficient because it actually returns a copy of the internal byte array. This is not a big problem with small-capacity data, however, as capacity increases, the efficiency of this approach is unnecessarily reduced. This class must copy the data because it cannot force read-only access to the resulting byte array. If it returns its internal buffer, then in general, the receiver cannot guarantee that the buffer is not modified concurrently by another receiver of the same array.

The StringBuffer class has solved a similar problem; it provides a writable character buffer, and it also supports efficient return of read-only strings that can be read directly from an internal character array. Because the StringBuffer class controls write access to its internal array, it copies its array only when necessary, that is, when it exports a String and then the calling program modifies StringBuffer. If no such modification occurs, any unnecessary replication will not be performed. The new I/O framework solves this problem in a similar way by supporting a wrapper that enforces a byte array of appropriate access control.

We can use the same common mechanism to provide efficient data buffering and re-read for applications that need to use the standard streaming APIs. Our example shows a class that can be substituted for the Bytearrayoutputstream class, which efficiently exports read-only access to the internal buffer by returning a read-only inputstream that directly reads an internal byte array.