Writing in the front

An article on this into the world of concurrent, please don’t miss to bring everyone the appetizer of concurrent programming, next we dinner on step by step, before eat dinner, I also quote poetry in the song: “cross the truth. which, far and near the different”, far see outline, close look at the details, or perspective to study constantly switch thinking

Looking at concurrency from a distance, concurrent programming can be abstracted into three core issues: division of labor, synchronization/collaboration, and mutual exclusion

If you are already working, you have heard of or are applying agile development patterns to deliver daily work tasks, we explain these three core issues in terms of processes that are familiar to you

Division of labor

Break the Story of the current Sprint into “appropriate” sized tasks and assign them to the “appropriate” Team members

There are two “fits” here, and it is important to break stories down into moderately sized, manageable tasks. The granularity of splitting is too coarse, resulting in high difficulty to complete the task, time-consuming, and difficult to cooperate with others; The granularity of the split is too fine, resulting in too many tasks that are difficult to manage and track, wasting energy and resources. (The right thread can better complete the block of work, of course, one thread can easily do not need multiple threads); It’s also important to assign the right people to do it. Ux-ue issues to back-end people are obviously problematic (the main thread should do what the child thread should do is obviously not able to solve the problem, each thread does the right thing to make a difference).

In terms of division of labor, common Executor, producer-consumer pattern, Fork/Join, etc., are all examples of this idea

Synchronization/collaboration

Task split is completed, I have to wait for Zhang SAN’s task, Zhang SAN has to wait for Li Si’s task, that is to say, there is a dependency between tasks, the front task is completed, the task behind can be executed, senior people can repeatedly confirm through communication, to ensure that their task can start to execute. But in the face of the program, we need to understand the communication mode of the program, one thread to complete the task, how to inform the subsequent thread to execute

All synchronization/collaboration relationships can be denoted by the if-then-else you’re most familiar with:

if{execute(); }else{
    wait();
}
Copy the code

The above code says: when a condition is not met, the thread needs to wait; When a certain condition is met, threads need to be awakened to execute. Cooperation between threads may be between the main thread and child threads, or between child threads and child threads. CountDownLatch and CyclicBarrier in the Java SDK are used to solve thread cooperation problems

The mutex

Division of labor and emphasize synchronization performance, but the mutex is emphasis on correctness, is the “thread safety”, we often mentioned when multiple threads access a Shared variable at the same time/member variables, the uncertainty may occur, causing uncertainty mainly have visibility, atomicity, the differentiation of the three questions, and mutual exclusion is the core to solve these problems

The mutex

Only one thread is allowed to access a shared variable at a time

If you look at the picture below, the trunk road is a shared variable, and only one car can enter the trunk road at a time, do you understand? As the saying goes, “Long separation makes great harmony.”

The Java SDK also has a number of mutually exclusive solutions, such as synchronized keyword, Lock, ThreadLocal, etc., which immediately come to mind

conclusion

The capitalists frantically extract the surplus value of the laboring workers to maximize their profits. When you’re dealing with CPU, memory, IO workers, you’re the capitalist, and you’re thinking, how do you get the most out of them

When a worker can do the work, never let two people to do (single thread can meet the need for multi-threading) when multiple workers work, it is necessary to let them clear division of labor, smooth cooperation, no contradiction

When the task is large, since the IO is slow and the CPU is fast, there is no need for the CPU to wait for the CURRENT IO to execute other instructions. This is how to maximize the value of the residual value, which involves subsequent tuning questions, such as how many threads are appropriate, etc

Division of labor is design, synchronization and mutual exclusion are implementation, no good design, there is no good implementation, so in the division of labor stage, I strongly suggest you draw sketches, understand the bottleneck, so as to have a better implementation, in the following chapters, I will lead you to draw sketches, analyze problems, and gradually develop this habit

The content of this chapter can be summarized by the following figure, we will gradually light up the content of the leaf node, do not pay too much attention at this stage (if you start to eat JDK source code, you may be painfully lost, and eventually give up your way to progress).

To understand the three core problems, you need to take into account the realities of life, the concurrency problems of programs, and basically all of them can be prototyped in real life

In the next article, we will talk about the three issues that cause thread safety: “visibility, atomicity, and orderliness”. This involves a bit of JMM that can be learned in advance so that we can have better collisions

Soul asking

  1. Are there many multithreaded programming scenarios at work?
  2. When you think of multithreading, do you only think of synchronized?
  3. Java and package each class, do you understand the underlying implementation and design concept?

Efficiency tools

Recommended reading

  • Use SpringBoot everyday, still do not understand RESTful API return unified data format how to achieve?
  • Parental assignment model: large factory high frequency interview questions, easy to fix
  • The interview doesn’t know the difference between BeanFactory and ApplicationContext.
  • How to design a good RESTful API
  • Red black tree, super static diagram details, easy to understand

Welcome to continue to pay attention to the public account: “One soldier of The Japanese Arch”

  • Cutting-edge Java technology dry goods sharing
  • Efficient tool summary | back “tool”
  • Interview question analysis and solution
  • Technical data to receive reply | “data”

To read detective novel thinking easy fun learning Java technology stack related knowledge, in line with the simplification of complex problems, abstract problems concrete and graphical principles of gradual decomposition of technical problems, technology continues to update, please continue to pay attention to……