Think back when a computer had only one CPU and could only process one program at a time. Then multitasking came along, which meant computers could handle multiple programs at the same time. Although it's not really "at the same time". A single CPU is shared between programs. The operating system will switch between running programs, executing one of them for a while before switching.
With the advent of multitasking, it is a new challenge for software developers. Programs cannot assume that all of the CPU is available at all times, or that all of the memory and other computer resources are available. A good program should release all resources it no longer uses so that other programs can use them.
Later, multi-threading appeared, which means that you can execute multiple threads in the same program. A thread can be thought of as a CPU executing a program. When you have multiple threads executing in the same program, it is like having multiple CPUs executing the same program.
Multiple threads can be a good way to increase the performance of some types of programs. However, multithreading is even more of a challenge than multitasking. This thread is executing in the same program, reading and writing the same memory at the same time. This may lead to errors not seen in single threads. Some of these errors may not be seen in single-CPU machines because the two threads never execute at the same time. Modern computers all have multi-core CPUs, and there are even multiple types of CPUs. This means that separate threads can be executed by separate cores or CPUs at the same time.
#If one thread reads a memory unit and another thread writes to it, what value will the first thread end up reading? Is this old one worth it? Or the value written by the second thread? Or is it a hybrid value between the two? Or if two threads write to the same memory location at the same time, what value will be left when they finish? Value written by first thread? Value written via second thread? Or is it a mixed value?
Without proper precautions, any of these outputs are possible. This behavior is even unpredictable. This output may change at any time. So it's important as a developer to know how to use the right safeguards - this means learning to control how threads access shared resources, like memory, files, databases, etc. That is one of the topics in this java concurrency tutorial.
Multi-threading and concurrency in Java
Java was the first language to make multi-threading simple and easy to use for developers. Java has had multi-threading capabilities from the beginning. Therefore, Java developers will often face the problems described above. This is why I wrote a series of articles about Java concurrency. Just like myself, any fellow Java developer will probably benefit from it.
This series will mainly be about Java multithreading, but some of the problems that occur in multithreading are similar to those that occur in multitasking and distributed systems. Multitasking and distributed systems may also be mentioned in this series. So the word "concurrency" is not just about multithreading.
Java Concurrency in 2015 and Beyond
Since the first Java concurrency book was written, in the world of Java concurrency frameworks and design A lot has happened, even since the Java 5 concurrency tools were released.
New, asynchronous "shared nothing" platforms and APIs like Vert.x and Play/Akka and Qbit have emerged. These platforms use different concurrency models compared to the standard Java concurrency model of threads, shared memory, and locks. New non-blocking concurrency algorithms have been released, and new non-blocking concurrency tools like LMAX Disrupter have been added to our toolkit.
With these new developments, it is also time for me to update the Java Concurrency Tutorial. Therefore, this tutorial is once again under revision. New tutorials will be released whenever there is time to write them.
The above is the introduction to 1.Java concurrency/multi-threading. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!