Regarding the synchronized keyword, I have searched a lot of information on the Internet, and there are many sayings. Some feel that they don't even say why, and then they just skip it. Some feel that they don't say that understandable reason. What kind of lock, object lock, global lock, and some people say whether the lock is an object or a code block, it feels very professional and complicated, but I still don't understand what's going on, it's not comprehensive, no Concrete, shy and incomprehensible. There are really a lot of various opinions on the Internet, and the more I look at it, the more I can't figure it out.
Finally, I still feel that it is more reliable after my own running test:
In fact, what synchronized locks is the object. Regarding synchronized(this), synchronized(xx.class), synchronized method, and static synchronized method, it is actually through whether the locked object is a singleton, whether it is the same object, who grabs the object first Resource, whoever executes the code in the synchronized braces first, the key is whether the locked object is unique. It has nothing to do with how many instances, global locks, etc.
Locked objects are like:
synchronized(this), this is the object, the synchronized method is the same as the synchronized(this) code block, but the scope of the synchronized function is different.
synchronized(xx.class), xx.class is this object, the static synchronized method is the same as the synchronized(xx.class) code block, and the scope of the synchronized function is different.
Below is the code and result of running the program:
synchronized(this), synchronized locked this object, that is, there is only one syncThread instance object, and two threads use the same object, so synchronized can play a role in controlling the security of multi-thread synchronization. Next, make a slight change.
It can be seen from the results that synchronized has not played the role of multi-threaded synchronization security, because the object locked by synchronized is s, and an instance object s will be recreated every time the run local method is called, and the locked object is not the same. It is not a shared resource, so it does not work, even if there is only one syncThread instance object, it does not work, because the locked object is not it. Next, make a few more changes.
Synchronized can play a role in controlling the security of multi-thread synchronization. Some people may ask, isn't str recreated every time the run local method is called? This is because it is of type String, which is different from StringBuffer. Those who know it know that the object of String is stored in the constant pool and re-created. It refers to the same object in the constant pool. The synchronized lock is still a shared one. Resource, whoever grabs it first will execute it first. Next, make a little change
It can be seen that synchronized can play a role in controlling the security of multi-threaded synchronization. The reason is that each class has a unique bytecode, which is a shared resource. There is only one single one. As for the synchronized modification method, the process will not be posted. It is the same as the synchronized block, but the scope of the function is different. The synchronized method is equivalent to synchronized(this), and the static synchronized method is equivalent to synchronized(this class.class).
The above output result is true, you can see that the reference values of classes and classi are equal, and they refer to the same object.
Next, post a process:
It can be seen that even if two threads one uses syncThread1 and two use syncThread2, synchronized can also play a role in controlling the security of multi-thread synchronization, because count is a static single shared resource, which is what synchronized locks, how much it has with SyncThread An instance object has nothing to do with it. This is just to emphasize again that synchronized is only related to whether the object it locks is single. If it is a single object, whoever grabs the object's resources first will execute it first, and other threads can only wait.
This is probably the case. The above is purely my humble opinion. I am old, and I wrote it down for my own convenience. You can read it if you are interested.