It also talks about the current situation and prospects of Java concurrent program design.

It is indeed the time when concurrency prevails. I think the most important reason is that the multi-core processor and its hardware system have become increasingly mature, and the cost has been reduced to the public price.

J. u. the c package is mainly designed for performance. Its design is not as good as the traditional built-in synchronization mechanism (synchronized block and method, and Object. wait (); Object. notify () is elegant, but the biggest drawback of the traditional synchronization mechanism is that it does not distinguish between shared synchronization (generally concurrent read operations) and mutex synchronization (generally write operations ), all synchronization operations can only be completely exclusive. As long as there is a possibility of concurrent writing, all read operations have to be synchronized with each other, thus losing the possibility of concurrent reading. This is a serious deviation from the concurrency mode of most applications (reading far and writing too much), so that the new concurrency capability of hardware will be largely discounted in common applications, this cannot be tolerated by the application software development market. At the same time, the traditional synchronization mechanism also has some flexibility disadvantages, such as Object. wait (); Object. Y (); must be executed in the synchronization block of the object (otherwise, IllegalMonitorStateException will be thrown), and an object can only be in the wait/notify State. The j. u. c Class enhances flexibility by enabling a Lock to create multiple conditions for wait/notify.

However, regardless of performance and flexibility, if the traditional Java synchronization mechanism can be implemented, it is still more elegant, and you will never be able to write the code that you forget to unlock after locking, because the {} does not match, a compilation error occurs. At the same time, there has been a considerable amount of research efforts to reduce the traditional synchronization mechanism to minimize synchronization overhead in a single thread, so that when the current JVM executes synchronization blocks, in the case of a single thread, the efficiency is very high. However, at the cost of multithreading, the performance is lower than reasonably imagined.

Excector, ScheduleExecutorService, Future, and BlockingQueue are actually Building blocks for Building application servers. Currently, they are provided as standard class libraries, helping to develop better Java frameworks, however, whether mainstream application development will also be based on these tool libraries at the grass-roots level, I personally have a wait-and-see attitude.

J. u. the c library is indeed better than the original dl. u. the performance of the c library will be high, because dl. u. c is built on the traditional Java synchronization mechanism, and j. u. c is to port it to the concurrent support feature of the latest JVM (through sun. misc. unsafe is used with the Hotspot VM to directly generate atomic memory access commands supported by the host CPU). It can be considered that the software implementation has been upgraded to the hardware implementation, and the performance difference can be imagined.

For distributed parallel computing/concurrent application programming, I am working on an open-source Apache framework called Hosting Based Interfacing, currently, Java Server and Flex/ActionScript3 clients have been implemented. If you are interested may wish to look at the http://hbi.googlecode.com, if you have time and energy together research development of course the best.