Java J. u. C series articles-Overview and basics

J. u. C is a seemingly simple and watery area of the Java series. However, whether it is something deep into Java or distributed, it is the foundation. Although I have written several multi-threaded articles in a mess before, however, they are all messy. Recently, I plan to write more articles to explain my small understanding of these things.

1. First, threads are divided into kernel threads and user threads. in Linux, Java threads actually have a user thread on the Java private stack and a lightweight process at the OS level.

2. When operating Java multithreading, the thread will inevitably encounter the lock problem. In the lock problem, the thread will first enter the collection of the so-called entry set, and then try to acquire the lock, the owner of the acquired lock is the owner who has not acquired the lock. When wait () is called, the lock enters the wait set area. After the lock is used up, the lock is released, call notfiy or policyall. Welcome to the wait set area and try again.
The information in the set is acquired together; there is no lock to call sleep; synchronized is a system-level lock; idle y is to wake up a waiting thread in the wait set area, and policyall is to wake up all relevant threads, join indicates that the current thread will wait for several corresponding threads to execute and then go down. If daemon is set to true, the background thread is automatically completed after the main thread is executed, otherwise, it will not; yield is the time for giving up a CPU for other threads, but no one knows how long it will take and how long it will sleep.

3. Blocked threads are usually suspended due to the locking mechanism or some network reasons, and interrupt cannot be disconnected at this time, the locking mechanism will be avoided in subsequent articles. However, for network mechanisms, Use SOCKET timeout sotimeout in Java to set the timeout, otherwise, it cannot be disconnected (including connecting to the database)SotimeoutIt indicates the connection timeout when a read operation occurs, that is, the connection timeout does not wait until the result is reached, rather than the total connection timeout;

4. Interrupt is only valid for wait and time_wait threads. If the program is in the cyclic running state, an interrupt command is initiated to stop the thread, at this time, the program will not be stopped by default, so when you look at some frameworks, there will be an operation inside the loop body:

Thread.currentThread().isInterrupted()

It is to determine that the current thread is interrupted. From this point, you can see that the interrupt is only a tag (True | falseIn this case, you find that the service is interrupted.BreakJump out of the loop. Note that another method is as follows:Interrupted ()This method not only sets whether the method is interrupted, but also sets the thread status to "not interrupted", that is, sets the status of interrupt to "false" again, but returns false currently, you can test the code in any main method:

Thread.currentThread().interrupt();System.out.println(Thread.currentThread().interrupted());System.out.println(Thread.currentThread().interrupted());//Thread.currentThread().interrupt();System.out.println(Thread.currentThread().isInterrupted());System.out.println(Thread.currentThread().isInterrupted());

Open the commented-out code and check the result. The source code is simple:

public boolean isInterrupted() {    return isInterrupted(false);}public static boolean interrupted() {    return currentThread().isInterrupted(true);}

As mentioned in the previous article about CPU cache line, we can see that if you want to set the cache in Java memory, it is recommended that these caches are basically not modified, it is best to use final; if it is a change to ensure visibility, You need to select volatile and ensure atomicity first select atomic *. If it is not necessary, do not play the lock by yourself, locking is especially implemented in static methods or classes. The description of visibility will be further elaborated in later articles.

5. Java now provides a lot of Java. util. the concurrent package replaces many of the original collection classes, but it does not mean that it can solve all the problems, it does not mean that the original collection classes are useless, and it does not mean that you do not need to understand the features and use cases of various collection classes; in the subsequent articles, we will introduce the details of these contents. In short, if you find that the content you want to access has multi-threaded access and they may be modified, there will be concurrency, concurrency has many problems that need to be addressed;

6. Some people think that it is acceptable if I do not ensure the correctness of the data or report an error during concurrency. I also think it is acceptable if I do not use non-parallel packet sending (such as hashmap). No, in the case of concurrency, sometimes it is not just an error. In some cases, it may cause duplicate key loops during concurrency.

7. The ABA problem is a painful problem. Even if many concurrent mechanisms are used to solve the problem, it may not be true. Therefore, Java provides us with a version control method for the ABA problem, subsequent articles will also be explained step by step.

8. threadlocal is a double-edged sword. It can beat you, but it can also beat you. threadload is very effective when passing parameters, and it is very convenient to add parameters, it is bound to the current thread, but it is difficult to check the problem, especially when these things are encapsulated in the three-way bag, because the web model thread will not be released, therefore, the internal parameters of threadlocal are not released, and the changes are unknown. The second cause is memory leakage.

9. JVM also provides you with a variety of thread pools. What can they do for you? What is the difference with normal threads? The processing model and Strategy of the thread pool; how to implement the functions of a scheduler through the thread pool; how to complete many realistic models through the thread pool without the need to write algorithms to solve complicated and disgusting thread interaction problems; here is another future and future task.

10. What exactly is the lock mechanism? How does Java play the lock? How does it know the lock? How does synchronized, lock (reentrantlock, readwritelock)? How does it choose to wait for the queue group? When is the deadlock, what are the deadlocks besides the cross deadlock? Trylock? How to improve performance?

11. introduction and use of queue, list, and map concurrent containers; countdownlatch, semaphone, cyclicbarrier, and exchanger tools; subsequent special introductions.

12. Atomic <basic variables>, atomic <basic variables> filedupdater, atomic <basic variables> array, atomicreference, and atomicstampedreference) and atomicmarkablereference (which can be counted;

In addition to the previous brief introduction, the subsequent sections will be a rough introduction. Due to space limitations, we can only gradually improve the subsequent content.