1 learning multithreaded fundamental objective knowledge
Multithreading knowledge of the fundamental objectives are: robust design of concurrent programs.
Of course, we can not answer this very practical problem (which related to a specific business, related to the specific strategies), This article focuses on the relationship between knowledge, beginners do not want to get lost in the API interface multithreaded tool class in.
Three macro issues 2 concurrent programs
Thread safety issues, performance issues, active issues. Relationship between the three is that in the process of designing a concurrent program to first ensure the security thread, the thread-safe on the basis of efforts to improve program performance, avoid the introduction of activity to ensure thread safety problems and improve performance.
Thread safety is the most important, concurrent program is designed to enhance the performance, but never forget that performance is built on the basis of security; and ensure the security (such as locking and synchronization methods) and optimization of concurrent performance ( the decomposition by the lock, the lock segment or the like) process, activity may introduce problems (such as deadlocks, hunger, livelock, problems such as poor responsiveness). This article focuses on knowledge thread safety issues.
3 thread safety
3.1 definition of thread safety
When multiple threads access a class that can consistently show correct the behavior , then call this class is thread-safe. The core concept is correct. Correctness implication is a class act and its specification exactly.
Like you have to design a dish, the ingredients and spices make up this dish must be controlled, that is, you can exact description of the results of operations of these ingredients and spices, such as canola will put incense, salt dishes would be salty, instant food and know when then salt, all elements that make this dish only to have clear and lucid design a dish is consistent with assumptions. When the design process is the same, only the use of the various variables and functions are controllable, design a program to run in accordance with the design. The use of multi-threading, may make certain variable composition and behavior of the program becomes uncontrollable .
3.2 Why Multithreading will bring thread safety issues
To clarify the thread-safety issues that need deep into JAVA memory model, not yet introduced here, here, with two life examples to illustrate the nature (atomicity issues and visibility problems) thread safety issues.
[ Example 1 ] to cooking for example. Operations which are salt, the salt can be decomposed into three steps operating "→ Check salts can be found salts are salts → canned food instant when the salt is poured into the dish." If only one person in the use of the salt shaker, then there would be no problem. However, before you if you "check the salt tank is loaded with salt" after the salt was poured into the dish, another man took the salt shaker, put the melamine milk powder, and the salt shaker back. This exchange process you do not know, you will finally replace the melamine milk poured over the dish, with predictable results. This is the thread safety issues atomicity problem .
Understand issues from atomic memory model : juejin.im/post/5d7760...
[ Example 2 ] A and B cooperate to cook rice as an example. There are three rooms (kitchen, fire control room, observation room), there is a kitchen pot with rice (on a piece of paper that says there are pot "has been cooked" or "immature"), A fire in the control room responsible off the heat (when looking at Turn off the heat to the paper says, "has been cooked on" pot), B is responsible for observing the state of meters in the observation room and change the status word (already cooked / immature) on pot stickers; a and B are not in a room, unable to communicate directly ; B will observe every one meter under the pot, if the rice cooked on a piece of paper to write "is ripe" immature to write "immature", B is busy, will finish his word paper attached to the door on, not affixed to the pot kitchen. The end result is, A word on the pot to see the state has been "immature", so do not turn off the heat, and ultimately rice paste. This is the visibility of the problem .
Understanding visibility problems from memory model : juejin.im/post/5d7760...
3.3 to solve the problem of atomicity and visibility of kernel memory
To write thread-safe code, its core is to be on the state (variables) access operations performed management , especially for sharing and variable access states.
Shared by multiple threads means that access operations, variable means that can be modified.
In the above-described Example 1, i.e., if the salt is not shared can not use other people, there will be no thread safety issues. If the provision can not go into the salt tank, the tank can only be removed from the salt, then no matter how much an individual can operate salt shaker salt shaker salt is always, no thread safety issues; Similarly, if a variable can not be modified, No matter how many threads operate this variable, it will not bring the thread-safety issues.
In Example 2 above, if the force B after modifying the status word, the paper attached to the pot, so that it can see the real status A rice, to timely turn off the fire, evaporated fragrant rice.
So, in order to solve the problem and atomic memory visibility problem, how to share and manage variable variables?
- Unless you need a domain is variable, otherwise it should be declared as final domain (ie declared as immutable)
- Parallel operations to the shared variable is converted to serial operation (e.g., synchronization mechanism, the synchronization variables entrusted to manage the container)
- Is converted to a shared variable is not shared variables (such as thread blocking (closed stack, ThreadLocal etc.))
- If an operation needs to be performed atomically, then wanted a way to ensure that this operation is atomically executed (such as to the operating lock)
- The need to ensure the visibility of the variable memory, a thread can be forced to read the variables from the cache rather than the main memory, is stored in a variable force the thread to access main memory. (Such as lock, declare volatile variable)
Remember, the core is a variable state managing shared lock (built-in lock, the lock Lock), synchronous containers (Vector, Hashtable, etc.), and transmits containers (ConcurrentHashMap, CopyOnWriteArrayList), synchronization tools (blocking semaphore, fences) , just so the thread pool is shared mutable state management tools.