Before, we've covered thread security earlier in this article and we'll continue to dig into this problem and continue to explore what thread safety, atomicity, and locking mechanisms are.
1, what is thread safety?
Thread-safe, there are two keywords, "shared" and "mutable".
Sharing refers to the simultaneous access of multiple threads;
Variable means that the value of a variable can change in the life cycle;
Whether an object needs to be thread-safe depends on whether it is accessed by multiple threads;
And how to ensure the thread safety of an object, you need to use synchronization mechanism to coordinate access to the variable state of the object.
Below, we give a clear definition of thread safety: When multiple threads access this class, if the class always shows the correct behavior, then the class is called thread-safe.
Here's a question I often like to ask the interviewer, is the servlet thread-safe?
In fact, there is no standard answer to this question. The key to this question is whether the servlet is stateful or stateless. What does it mean to be stateful? To put it simply, a global variable is defined in the servlet, and then in the relevant Doservice or Doget, Dopost and other methods, the global variable is updated, then this time it is state, and vice versa is stateless. When there is a state, you need to consider thread-safe handling, otherwise you do not need to.
Come, we give you a conclusion:
Stateless objects must be thread-safe.
multithreaded environment, multiple threads share a resource, and do not do atomic operations, this time to consider the thread of security control problems
2, Atomic
We also said in the previous article that this problem, such as a simple operation, count++, in fact, is not atomic, because this step will actually be split into three steps, that is, read---modify---write, and these three steps may at some point due to the CPU time slice switching problem, Only one or two of these steps are performed, which is not atomic.
In the JDK, in order to solve this problem, Java.util.concurrent.atomic package provides a lot of classes to ensure the atomicity of data operations, such as our previous program can be modified to
public class System {
Private Atomicinteger integer = new Atomicinteger (0);
public int GetCount () {
return Integer.incrementandget ();
}
}
3, lock mechanism
As described above, we know that when a class contains a stateful variable, it can be done with a thread-safe object, but here's a reminder that if a class contains multiple stateful variables, This time is not simply add a few thread-safe objects to solve the problem.
A criterion of judgment is that, as long as there is a "Judge first, then update" in the program, it is necessary to ensure that the two operations in an atomic operation in order to ensure thread safety.
Some of the characteristics of the Java lock mechanism, I am here with you to list:
Built-in locks, monitoring locks, mutexes, reentrant locks are all features of this lock
Built-in lock, monitoring lock: These two are meant to mean that every object in Java can be used to do a built-in lock, which is why our wait, notify method is defined in the object class.
Mutex: Indicates that only one thread can hold this lock at most.
Reentrant Lock: When thread A requests a lock held by thread B, thread B goes into a blocking state, and if thread a accesses another piece of code, and the lock of the code is already held by thread A, this time the request can be successful, which is called reentrant.
Let's talk about the principle of this lock implementation:
The JVM sets two properties for each lock, gets the count value and the owner thread, and when the count value is 0 o'clock, the lock is considered not to be held by any thread, and when the thread requests an unlocked lock, the JVM records the holder of the lock and counts the value +1. If the same thread acquires the lock again, the count value is incremented, and when the thread exits the synchronization code block, the counter decrements accordingly, and when the count is 0, the lock is freed.
If you have any questions, welcome message, leave a message I do not necessarily have time to answer ...
Binary Viewer can view bytecode files
Byte-code content can also be seen through Javap-verbose *.class
High concurrency programming -04-thread Security