Shortcuts to multithreading development: Build a Java concurrency model framework

Java multithreading features provide great convenience for building high-performance applications, but it also brings a lot of trouble. Thread synchronization, data consistency, and other cumbersome issues need to be carefully considered. If you are not careful, there will be some subtle and difficult debugging errors.

In addition, application logic and thread logic are entangled, which will lead to chaotic logic structure of the program, making it difficult to reuse and maintain the program. This article attempts to provide a solution to this problem. By constructing a framework for concurrent models, it is easy to develop multi-threaded applications.

Basic knowledge

The Java language provides good support for threads, and the implementation method is small and elegant. For method re-entry protection, the semaphores (semaphore) and critical sections (critical section) mechanisms are all very simple. It is easy to implement synchronization between multiple threads to protect the consistency of key data. These features make Java a leader in supporting multithreading in object-oriented languages (C ++ is trying to include thread support in the boost library into language standards ).

Java has built-in support for concurrent object access. Each object has a monitor, and only one thread can hold the monitor to access the object, the threads that do not obtain the monitor must wait until the threads that hold the monitor release the monitor. The object uses the synchronized keyword to declare that the thread must obtain the monitor to access itself.

The synchronized statement is only effective for some simple inter-thread synchronization issues. Java provides an additional solution for complex synchronization problems, such as synchronization problems with conditions, wait/notify/notifyAll.

The thread that obtains the object monitor can actively release the monitor by calling the wait method of the object, waiting for the thread of the object to wait for the queue. In this case, other threads can obtain the monitor to access the object, then, you can call the Y/notifyAll method to wake up the thread waiting for calling the wait method.

Generally, the wait/notify/notifyAll method is called based on certain conditions, such as the null or full queue determination in typical producer/consumer problems. Readers familiar with POSIX will find that using wait/notify/policyall can easily implement an advanced synchronization technology between threads in POSIX: conditional variables.

Simple Example

This article will focus on a simple example, so that we can more easily highlight the ideas and methods for solving the problem. This article is intended to show readers exactly these ideas and methods. These ideas and methods are more suitable for solving concurrency problems in large-scale and complex applications. Consider a simple example. We have a service provider that provides external services through an interface. The service content is very simple, that is, printing Hello World on the standard output. The class structure is as follows:

The Code is as follows:

Interface Service {public void sayHello ();} class ServiceImp implements Service {public void sayHello () {System. out. println ("Hello World! ") ;}} Class Client {public Client (Service s) {_ service = s;} public void requestService () {_ service. sayHello () ;}private Service _ service;} if there is a new requirement, the Service must support concurrent access from the Client. A simple method is to add the synchronized statement before each method in the ServicImp class to ensure internal data consistency (of course, this example is not necessary at present, because ServiceImp does not have data to be protected, but it may be available in the future as the demand changes ). However, at least the following problems may occur:

1. now we need to maintain two versions of ServiceImp: multi-threaded version and single-threaded version (in some places, such as other projects, there may be no concurrency issues), which may lead to problems of simultaneous updates and correct version selection, it brings trouble to maintenance.

2. If multiple concurrent clients frequently call the service, the Client will be blocked and the service quality will be reduced because the service is directly called synchronously.

3. It is difficult to implement flexible control, such as queuing based on the Client priority.

4. These problems are especially prominent for large multi-threaded application servers. Some simple applications (such as the example in this article) may not be considered at all. This article discusses the solutions to these problems. The simple examples in this article only provide a platform to illustrate the problem and demonstrate the ideas and methods.

5. How can we better solve these problems? Is there a reusable solution? Let's take a look at these issues first. Let's talk about some framework-related issues first.