Multithreading for Java

As a tool for developing software, programming language can communicate with computers. Everyone has a reason to choose a tool. I chose Java for the following reasons: strong standards ensure many low-level errors and hard-to-find errors are checked during compilation; strict memory management, there are strict rules for memory access to Java, it can prevent array subscript out of bounds, wrong memory access; high-performance garbage collector, after the emergence of the CMS concurrent collector, Java performance has taken a step, and Java virtual machines are constantly developing and improving, Java performance will also be greatly improved, and Java performance problems have gradually become a pass-through; multithreading and multithreading are the advantages of Java. the Java language has made great effort in this regard, making Java's multithreading performance and security so powerful. These reasons make me very fond of learning and researching Java language.

This article describes Java multithreading. As many Java programmers know, Java multithreading involves many precautions. This blog post mainly introduces some topics and discusses them. If you want to discuss it in depth, each topic can be explained in several blog posts. The following are some topics to be discussed:

1. Why multithreading (advantages of multithreading)

2. What is the problem with multithreading (the problem to be solved by multithreading)

3. Java multi-threaded specifications (JVM specifications for Java to solve multi-threaded problems)

4. Java methods to solve multithreading, including synchronized, reentrantlock, volatile, final, threadlocal, stack closed, and juc technology)

The first topic:

There are many reasons to use multithreading. In general, there are the following (may not be all ):

1. Try to use system resources to reduce the task completion time. (For example, CPU and distributed computing mapreduce can be used when I/O is blocked)

2. Multi-task system. Some tasks need to be executed in parallel. (For example, You need to respond to user interruption requests)

3. You need to provide services to more people at the same time. You cannot make short tasks unavailable because a long task fully occupies system resources. (For example, Web servers)

4. A server can have a lot of CPUs (a single CPU can also support hyper-threading), so multithreading is an inevitable trend.

The second topic:

There are indeed many uncertainties in multithreading. It is also difficult to debug programs like serializing execution. The problem may take a certain amount of running time and a certain sequence of operations. So many programmers are avoiding this problem and are afraid to use multithreading. Therefore, the first problem to be solved by multithreading is psychological fear. Technically, multithreading has two main problems to solve. This is also a question that must be considered when developing multi-threaded programs.

1. Share Data visibility (when data written by one thread is visible to other threads ).

2. Competition for shared resources (when multiple threads request a resource at the same time, who is the first, such as counting or transferring money ).

Note that there is a shared word here, that is, a problem occurs only when resources are operated simultaneously in multiple threads. The following describes the causes and scenarios of these two problems.

For visibility issues:

The execution speed of the CPU is so high that the bottleneck of the computer's execution speed is I/O. In addition to the CPU register cache, there are also L1 and L2 independent caches on the CPU and L3 shared caches in the same CPU slot. Then the primary storage, disk, network, and so on. When the CPU needs to access data, it reads and writes data along the cache above sequentially. Taking writing as an example, if a copy of data is stored in the primary storage, it will be loaded into the register cache layer by layer. If cpu0 needs to change the value of the data, it will first be written to the Register cache, at this time, the data will not immediately modify the data in the primary storage. If the second CPU reads the data again, it will not read the previous change value but will read a "dirty" value. That is, the first operation is invisible to the second operation. At this time, the second CPU may be determined based on the conditions to handle this value. Because it is invisible, it may cause problems such as failure of judgment and loss of updates. Invisible problems may also be caused by re-sorting.

Resource Competition Issues:

The question of resource competition is actually very understandable, such as counting a variable. Because the count can be divided into three steps: read, change (depending on the original value for modification), and replace. If multiple threads execute these three steps without any restrictions, other steps will become invalid. There is also a problem of hashmap resizing, which can only occupy resources for printers. These are some problems of resource competition. Resource Competition is far from that simple, especially in high concurrency, but it may also lead to some hardware problems. This is also the difficulty of multithreading. Resource Competition problems may also be caused by re-sorting.

The third topic:

Java has proposed a jmm model for multithreading. This model is mainly for the visibility Convention-happens-before principle. Happens-before has the following conventions:

(1) Each instruction in the same thread is happens-before in any instruction that appears after it.

(2) unlocking a monitor happens-before locks each subsequent to the same monitor.

(3) write the volatile field happens-before for subsequent read operations on this field.

(4) for final modified variables, the construction of happens-before is prior to the first access to it.

(5) the call of thread. Start () will call the action of happens-before in the startup thread.

(6) All actions in thread are returned by happens-before in other threads to check whether the thread ends or thread. Join () or thread. isalive () = false.

(7) When thread a calls interrupt () of thread B of another thread B, both happens-before and thread a find that thread B is interrupted by thread A (B throws an exception or a detects isinterrupted () of thread B () or interrupted ()).

(8) End of an object constructor: The beginning of happens-before and finalizer of the object

(9) If action a is in action B and action B is in action C, Action A is in action C.

These happens-before conventions solve the visibility issue of shared variables. The competition for shared resources mainly relies on the lock synchronized and lock, and the lock-free CAS operation.

The fourth topic:

The variable modified by final is an immutable object (if it is a reference type, but the reference is immutable, its value is also changeable ). Therefore, using final to modify shared variables can greatly reduce the complexity of multi-threaded access. Because immutable objects must be thread-safe. Constructing immutable objects is a good programming habit.

Stack blocking means that there is no shared variable, and all variables are allocated in the method stack of this thread. It is not passed to other threads for use. This actually avoids the multi-thread sharing problem, and we still need to share it in many cases.

Threadlocal, which is another technology that avoids multi-thread shared variables (shared only to this thread ). It binds the object to the threadlocalmap on the thread. This is a map referenced by a weak key. The key is threadlocal, and the value is the object shared by a specific local thread. Therefore, such an object can be recycled in two ways. The first threadlocal instance loses the strong reference, which may be recycled during GC. The second thread loses the strong reference and is recycled as the thread is recycled. Therefore, threadlocal does not cause memory overflow. Using remove to remove unnecessary variables is a good habit. If the thread runs threadlocal for a long time, it usually does not lose the strong reference, so the content here cannot be recycled.

The volatile variable is mainly a constraint on visibility, that is, its write operations can be immediately seen by the next read thread. However, it does not guarantee atomic operations.

Synchronized is a built-in lock on objects or classes. Code within the scope of synchronized cannot be reordered, and the latest state can be seen when the shared variable is read. Written shared variables can be immediately visible to other objects holding the lock.

Reentrantlock provides the same features as synchronized. The main difference between them is that

1. The reentrantlock must be released by itself. It is usually released in finally.

2. reentrantlock can control the fairness of multi-threaded access through parameters.

3. reentrantlock can be obtained through trylock (), non-blocking locks, or within the specified wait time. Once synchronized enters the lock competition, it must wait for the lock, so it is easier to generate a deadlock.

4. reentrantlock can respond to interruptions, while synchronized cannot respond to interruptions. This is important! A good thread design must respond to interruptions.

Many juc packages are mainly multithreading tools. Here we mainly talk about CAS operations. Atomicxxxx uses CAS instead of a lock. Therefore, it is more efficient than lock synchronization. CAS operations are mainly supported by CPU hardware. Juc content a lot of here is not discussed separately, interested students can read this blog, http://blog.csdn.net/xieyuooo/article/details/8594713

The multi-thread discussion is now here. If you have any flaws, please point them out. Thank you!