Concurrent programming directory

In my spare time, I have written a total of more than ten in-depth articles on Java concurrent programming. Since the contents are quite large, I have listed a table of contents here for your convenience.

As you learn about concurrent programming, you’ll be exposed to the keyword volatile, which modifates members that are visible across multiple threads. To understand its implementation, you’ll need to first understand the Java memory model, the JMM. So volatile and JMM are the beginning of the concurrency series:

  • Java Memory Model (JMM) and Volatile Keyword Fundamentals

Multithreaded programming, is bound to involve concurrency safety issues, and Java provides the native synchronized keyword as an implicit lock, to ensure thread safety between multiple threads. Its internal coverage of knowledge is more, need to understand the place is not much. The second/third article is around the synchronized keyword from the basic application to the JVM source code, a comprehensive analysis of its principle:

  • (2) fully Understand the Implementation principle of Synchronized keyword in Java Concurrent Programming
  • (3) “The in-depth analysis of Hotspot source code Synchronized keyword implementation”

When it comes to Java JUC and sending packets, CAS mechanism is applied as a basis to realize concurrent components in a large number of its internal components. Meanwhile, CAS technology is also used to ensure the safety of thread execution. CAS mechanism is the key to realize the lock-free strategy. In Java, the CAS mechanism relies on the native operation implementation provided by the Unsafe magic class, which is also the core of the JUC atomic package. Examining the broadening of the Unsafe magic class and the source code for the Atomic Atomic package, the following article explores the CAS mechanism.

  • (4) “Unlockable CAS for Java Concurrent Programming”, “Unsafe”, “Atomic”

As mentioned earlier, CAS is the cornerstone of JUC and packet dispatch, so AQS is the core of JUC and packet dispatch. AQS, as a special presence in JUC packages, relies on the spin and CAS mechanism downward, and provides the implementation of a synchronizer upward. It does not directly serve external services, but serves as a basic component for other concurrent components in JUC packages. Common concurrency tools such as ReetrantLock, Semaphore, and CountDownLatch. The following two articles make a comprehensive analysis of AQS from the exclusive mode and the shared mode respectively:

  • (5) An In-depth Analysis of Concurrent AQS Exclusive Lock & ReetrantLock and the Realization Principle of Condition
  • (6) Hand Rip Concurrent Programming Based on Semaphore and CountDownLatch Analysis of AQS Sharing Mode Implementation

After talking about the AQS, previous articles, the solution to the problem of concurrent security there the implicit lock scheme, no lock strategy, explicitly exclusive lock as well as four Shared lock mode, and then to talk about a ThreadLocal is doing the opposite, from the perspective of Shared variables copy copy, avoid the multithreaded competition, so as to solve the problem of thread safety. It is an important means of preventing concurrency problems:

  • (7) “A Comprehensive Analysis of the Principle of Java Concurrent Programming thread Variable Copy ThreadLocal”

Back to the basics, when we learn Java concurrent programming, we are familiar with the creation of multithreading, Thread class inheritance and implementation of Runnable, Callable interface. In fact, there is only one way to create multiple threads, and that is to inherit the Thread class, because only this way can truly map an OS kernel Thread execution, Runnable, Callable objects can only be called a multithreaded task. No type of task can be created with truly asynchronous callbacks, and the CompletableFuture introduced in Java8 is the real game-changer. The following article provides a comprehensive analysis of multi-threaded tasks:

  • (8) Analysis of the Principle of Runnable, Callable, FutureTask and CompletableFuture for In-depth concurrency

In the process of multi-threaded development, the previous containers such as HashMap and ArrayList will have security risks in the multi-threaded environment, while HashTable, Vector and other safe containers sacrifice a lot of performance in exchange for thread safety, and they often cannot meet the growing needs of users. The JUC package also provides a large number of concurrent containers, which can ensure thread safety while also performing well in terms of performance. The ninth article from the source perspective of a comprehensive analysis of Java common concurrent containers:

  • (9) “In depth concurrent Programming concurrent container: Blocking queue, write copy container, lock fragment container principle in detail”

In the previous article, we looked briefly at concurrency tools and then looked at the ThreadPoolExecutor system, a member of the Java thread pool family that manages, schedules, and monitors threads created in Java programs while simultaneously reusing a single thread. ThreadPoolExecutor (ThreadPoolExecutor, ThreadPoolExecutor, ThreadPoolExecutor, ThreadPoolExecutor, ThreadPoolExecutor)

  • (10) In-depth understanding of Java Concurrent Programming thread Pool, Working Principle, Reuse principle and source code Analysis

In Java7, the Fork/Join framework was reintroduced as an implementation of the didivide and conquer idea in Java and as a complement to the ThreadPoolExecutor framework. It also lays a solid foundation for parallel flow technology in Java8. ForkJoinPool also maximizes the performance of multi-core machines by employing an internal work-stealing algorithm to ensure that each thread is fully loaded. However, the overall implementation of Fork/Join framework is too large, which is illustrated in two articles of more than 30,000 words:

  • (11) “A Thorough Understanding of the Product of JUC Divide and Conquer: Analysis of The Principle of ForkJoin Branch Combination Framework (Part I)”
  • (12) “A Thorough Understanding of the Product of JUC Divide and Conquer: An Analysis of the Principle of ForkJoin Branch Combination Framework part II”

Most of these articles, the vast majority of the situation we are in the surrounding multi-threaded thread safety problem between writing, but they are based on an analysis of the monomer architecture of Java program, and now the era of monomer architecture has long gone, the general is a Java program by more machines, distributed architecture model for deployment. Do the CAS lock-free, implicit, and explicit locking schemes still work in multi-deployment environments? The answer is no. Under the new architecture, a new solution to the thread safety problem needs to be introduced: distributed locking. In the final article, from the security issues under distributed architecture to Redis and Zookeeper to implement distributed lock principle analysis, a comprehensive description is given:

  • (13) Comprehensive Understanding of Redis and ZK Distributed Locks in the Distributed Architecture of Concurrent Programming

At this point, the whole concurrent programming series comes to an end, and the missing pieces will have a chance to be filled in.

In the foregoing, concurrent tools and concurrent safety issues have been elaborated, while some other problems of concurrent programming have been ignored, such as deadlocks, live locks, lock starvation and other problems, and some concepts such as threads, processes, fibers, coroutines and so on have not been described, but now I add at the end:

  • [(14) “In-depth understanding of concurrent threads, processes, fibers, coroutines, pipes and deadlocks, live locks, lock starvation”](juejin.cn/post/704039…

The above article is generally based on the underlying, principle source code and other in-depth analysis, although can not guarantee absolute authority, but at least for you to understand Java concurrent programming pave the way! If you have any questions about this article, you can correct them in the comments section!

At the same time, if you feel the article is helpful to you, welcome to like, comment, favorites, follow!

Next announcement: In-depth Understanding of Java Virtual Machine JVM series

First, a personal drawing of the JVM diagram for everyone to enjoy: “In-depth understanding of the Java Virtual Machine JVM panorama Architecture Diagram”

Body and mind must always be on the road, or travel, or study!