计算机外文文献及翻译.doc

Exploiting ThreadLocal to enhance scalability The ThreadLocal class appeared with little fanfare in version 1.2 of the Java platform. While support for thread-local variables has long been a part of many threading facilities, such as the Posix pthreads facility, the initial design of the Java Threads API lacked this useful feature. Further, the initial implementation was quite inefficient. For these reasons, ThreadLocal gets relatively little attention, but it can be very handy for simplifying the development of thread-safe concurrent programs. In this third installment of Threading lightly, Java software consultant Brian Goetz examines ThreadLocal and offers tips for exploiting its power. Participate in Brians Multithreaded Java programming discussion forum for help with threading and concurrency issues in your projects. Writing thread-safe classes is difficult. It requires a careful analysis of not only the conditions under which variables will be read or written, but also of how the class might be used by other classes. Sometimes, it is very difficult to make a class thread-safe without compromising its functionality, ease of use, or performance. Some classes retain state information from one method invocation to the next, and it is difficult to make such classes thread-safe in any practical way. It may be easier to manage the use of a non-thread-safe class than to try and make the class thread-safe. A class that is not thread-safe can often be used safely in a multithreaded program as long as you ensure that instances of that class used by one thread are not used by other threads. For example, the JDBC Connection class is not thread-safe -- two threads cannot safely share a Connection at a fine level of granularity -- but if each thread had its own Connection, then multiple threads can safely perform database operations simultaneously. It is certainly possible to maintain a separate JDBC connection (or any other object) for each thread without the use of Thread