Do not use both the Reentrantlock class and the Synchronized keyword to lock different methods for modifying the same resource

Transfer from http://agrael.iteye.com/blog/685840

This article is about the problem of using the Reentrantlock class with the Synchronized keyword, not the Reentrantlock class and the Synchronized keyword tutorial.
The Synchronized keyword is one of the most important keywords in Java multithreaded programming, and it maintains security in this thread concurrency. There are 2 ways to use synchronized generally.
Lock the current instance

Java code

2. Use synchronized on methods to achieve locking effect
4. Public synchronized void xxx () {
6. //...  
8. }
12. Locks the specified instance by locking it to the desired effect
14. Public void yyy () {
16. synchronized (this) {
18. //...  
20. }
22. }
26. Public void zzz () {
28. synchronized (xObject) {
30. //...  
32. }
34. }

The first and second are those of the object instances to which the current method belongs, and the third is to lock the specified instance.
This article does not intend to explain in detail the Synchronized keyword, the detailed description of the synchronized please refer to other materials.


The lock framework in Java.util.concurrent.lock is an abstraction of locking, which allows the implementation of a lock to be implemented as a Java class, rather than as a language feature. Reentrantlock is an implementation of the lock interface that defines the reentrant lock. According to the API's description: "A reentrant mutex lock lock, which has the same basic behavior and semantics as the implicit monitor lock accessed using the Synchronized method and the statement, but is more powerful." "It can be found that the most basic function of Reentrantlock is to implement the same basic behavior and semantics as the implicit monitor lock accessed using the Synchronized method and the statement."
Reentrantlock provides a lot of methods, but here we only discuss how to implement synchronized the same functionality.
Examples used in the API are:

Java code

2. Class X {
4. Private Final Reentrantlock lock = new Reentrantlock ();
6. // ...  
10. public void M () {
12. Lock.lock (); //block until condition holds
14. try {
16. //... method body
18. } finally {
20. Lock.unlock ()
22. }
24. }
26. }

As you can see, if the above code is replaced with synchronized, it should be:

Java code

1. Public synchronized void m () {
2. //... method body
3. }

Or

Java code

1. Public void M () {
2. synchronized (this) {
3. //... method body
4. }
5. }

The current instance is locked. This is also the focus of this article. (For more information on Reentrantlock, please refer to other materials)
Since Reentrantlock and synchronized both provide the same behavior (no performance issues are discussed here), it is possible to use Reentrantlock and synchronized for threading concurrent programming in the process. They can all work very well, too. But what if you use them two at a time? What would be the result?
Look at the following code:

Java code

2. Package cn.agrael.test.thread;
6. Import Java.util.concurrent.locks.ReentrantLock;
10. Public class Reentrantlockandsynchronized {
14. Private Final Reentrantlock lock = new Reentrantlock ();
18. Private volatile int i = 0;
22. public void Lockadd () throws Exception {
24. Lock.lock ();
26. try {
28. Check ("Lockadd");
30. i++;
32. i++;
34. } finally {
36. Lock.unlock ();
38. }
40. }
44. public synchronized void Synchronizedadd () throws Exception {
46. Check ("Synchronizedadd");
48. i++;
50. i++;
52. }
56. public void Synchronizedadd () throws Exception {
58. Lock.lock ();
60. try {
62. Check ("Lockadd");
64. i++;
66. i++;
68. } finally {
70. Lock.unlock ();
72. //      }
74. //  }
78. private void Check (String methodName) throws Exception {
80. if (i% 2! = 0) {
82. throw New Exception (MethodName + ":" + i);
84. }
86. }
90. public static void Main (string[] args) throws Exception {
92. final reentrantlockandsynchronized add = new reentrantlockandsynchronized ();
94. Thread thread1 = new Thread (new Runnable () {
98. public Void Run () {
100. try {
102. While (true) {
104. Add.lockadd ();
106. }
108. } catch (Exception e) {
110. E.printstacktrace ();
112. System.exit (0);
114. }
116. }
118. });
120. Thread thread2 = new Thread (new Runnable () {
124. public Void Run () {
126. try {
128. While (true) {
130. Add.synchronizedadd ();
132. }
134. } catch (Exception e) {
136. E.printstacktrace ();
138. System.exit (0);
140. }
142. }
144. });
146. Thread1.start ();
148. Thread2.start ();
150. }
152. }

There is an I variable of type int, and provides a Lockadd method using Reentrantlock locking and a Synchronizedadd method that uses synchronized locking, all 2 methods provide the same operation, first verifying whether I is an even number, Throws an exception if it is not, and provides 2 times i++ operation. Java i++ is not atomic operation, will involve reading and writing, and also provide 2 times i++, if so, there will be concurrency problems, so we provide reentrantlock and synchronized to lock, to ensure thread safety. If our ideas are workable, then I will always be read with even numbers, and we will never throw out the exceptions we specify. But the result is not so, after running for a while, throws an exception, proves that our idea failed. Because Reentrantlock and synchronized provide different mechanisms, they are relatively independent, which is equivalent to two locks, each locking their respective.
So in the end, we concluded that not using both the Reentrantlock class and the Synchronized keyword lock will modify different methods of the same resource.

Do not use both the Reentrantlock class and the Synchronized keyword to lock different methods for modifying the same resource