Java Theory and Practice: concurrency to some extent makes everything easier

Most of us will never consider writing these utilities ourselves when you need XML parsers, text indexing programs, and search engines, regular expression compilers, XSL processors, or PDF generators in your project. Whenever these facilities are needed, we use a commercial or open source implementation to perform these tasks for the simple reason that the existing implementations work well and are easy to use, writing these utilities yourself will be less effective, or even result-free. As software engineers, we prefer to follow Isaac Newton's belief that standing on the shoulders of giants is sometimes desirable, but not always. In Richard Hamming's Turing award lecture, he argued that computer scientists were more "self-reliant". ）

Exploring the causes of repeated inventions of "wheels"

For low-level application framework services (such as logging, database connection pooling, caching, and task scheduling) that are required by almost every server application, we see these basic infrastructure services rewritten over and over again. Why is this happening? I don't think it's necessary because the existing options are not sufficient, or because the custom version is better or more appropriate for the application at hand. In fact, a custom version developed specifically for an application is often not more appropriate for the application than a widely available, general-purpose implementation, and may be worse. For example, although you don't like log4j, it can accomplish tasks. Although the logging system you develop may have some specific features that log4j lacks, for most applications it is hard to prove that a sophisticated custom logging package is worth the cost of writing from scratch, rather than using an existing, general-purpose implementation. However, many project teams end up writing logging, connection pooling, or thread dispatch packages over and over again.

It looks simple on the surface.

One of the reasons we don't consider ourselves writing an XSL processor is that it will take a lot of work. But these low-level framework services look simple on the surface, so it doesn't seem difficult to write them yourself. However, they are difficult to work properly, and are not as they seem at first. The main reason these special "wheels" have been repeatedly invented is that, in a given application, the need for these tools is often very small, but when you encounter the same problems that exist in countless other projects, the demand becomes larger. The reason is usually like this: "We don't need perfect logging/scheduling/caching packages, just some simple packages, so we just write some packages that can achieve our goals, and we will adjust it for our specific needs." Often, however, you quickly expand the simple tool you write and try to add more features until you write a sound infrastructure service. At this point, you are usually stuck with the program you write, whether it's good or bad. You've paid the full price for building your own program, so you have to overcome this "paid cost" hurdle in addition to the migration costs that you actually put into the common implementation.

The value of concurrent artifacts

Writing schedules and concurrent infrastructure classes is really harder than it looks. The Java language provides a useful set of low-level synchronization primitives: Wait (), notify (), and synchronized, but the specific use of these primitives requires some skill, including performance, deadlock, fairness, resource management, and how to avoid the hazards of thread security. Concurrent code is difficult to write and more difficult to test-even if an expert sometimes gets an error at the first time. Doug Lea, author of Concurrent programming in Java (see Resources), wrote an extremely good, free concurrent utility package that includes locks, mutexes, queues, thread pools, lightweight tasks, a valid concurrency collection, the original The arithmetic operation of the child and other basic components. This package is generally referred to as util.concurrent (because it has a very long actual package name) that will form the basis of the Java.util.concurrent package in the Java Community process JSR 166, which is being standardized in JDK 1.5. At the same time, Util.concurrent has been well tested and many server applications, including the JBoss Java application Server, use this package.

Fill in the blanks

A set of useful advanced synchronization tools (such as mutexes, signaling and blocking, and thread-safe collection classes) are omitted from the core Java class library. The Concurrency Primitives ―synchronization, wait (), and notify () of the Java language are too low-level for the needs of most server applications. What happens if you try to acquire a lock, but if you timeout in a given time period and haven't got it? If the thread is interrupted, the attempt to acquire the lock is discarded? Create a lock that can hold at most N threads? Support for locking in a variety of ways (such as concurrent reads with mutexes)? Or get the lock in one way, but release it in another way? The built-in locking mechanism does not directly support these scenarios, but it can be built on the underlying concurrency primitives provided by the Java language. But doing so requires some skill, and error prone.

Server application developers need simple facilities to perform mutexes, synchronize event responses, cross-activity data communications, and asynchronously dispatch tasks. For these tasks, the low-level primitives provided by the Java language are difficult to use and error prone. The purpose of the Util.concurrent package is to fill this gap by providing a set of classes for locking, blocking queues, and scheduling tasks so that you can handle some common error conditions or limit the resources consumed by task queues and running tasks.