Forwarding: Java Threads: mutexes and read-write locks

Original link: http://coolxing.iteye.com/blog/1236909

Two types of mutex mechanisms:

1, synchronized

2, Reentrantlock

Reentrantlock is a new feature of Jdk5, the use of Reentrantlock can completely replace the replacement synchronized traditional locking mechanism, and the use of Reentrantlock way more object-oriented, but also more flexible, Online there are a lot of comparison between the two lock way article, here is not more words, we Baidu, Google a little to the bottom of the story. In this blog also wrote about the two types of lock implementation of the classic example of "producer consumers."

Synchronized way: Java threading: Three ways to implement producer consumer issues _1

Reentranlock Way: Java threading: Three ways to implement producer consumer issues _2

With regard to read and write locks, the interpretation of the language is not as straightforward as the code interpretation, the following two examples of reading and writing locks and read-write lock use:

Example 1:

[Java]View Plaincopy

2. Import Java.util.HashMap;
4. Import Java.util.Map;
6. Import Java.util.concurrent.locks.ReadWriteLock;
8. Import Java.util.concurrent.locks.ReentrantReadWriteLock;
12. /**
14. * @author amber2012
16. *
18. * Read/write Lock: Readwritelock
20. *
22. * In multi-threaded environment, the same data to read and write, will involve thread safety issues. For example, when one thread reads the data, another thread
24. * Write data, resulting in inconsistent data; When a thread writes data, another thread is writing, and the data that is seen before and after the thread
26. Inconsistency
28. *
30. * In this case, you can add a mutex in the read-write method, at any time can only allow one thread of a read or write operation, and not allow other threads to read or write operations, which
32. * Sample can solve such problems, but the efficiency is greatly reduced. Because in a real business scenario, the number of times the data is read is usually high
34. * In the operation of writing data, while the thread-to-thread read operation is not related to thread safety issues, there is no need to join the mutex, as long as the read-write, write-write period
36. * It's OK to lock the room.
38. *
40. * For this case, read/write lock is the best solution!
42. *
44. * Mechanism for reading and writing locks:
46. * "Read-read" is not mutually exclusive
48. * "Read-write" mutex
50. * "Write-write" mutex
52. *
54. * i.e. at all times must be guaranteed:
56. * Only one thread is written;
58. * When the thread is reading, the write operation waits;
60. * When the thread is writing, the other thread writes and reads the operation to wait;
62. *
64. * The following is a cache class: an operation to demonstrate a read-write lock: Re-entry, demotion
66. */
68. Public class Cacheddata {
72. //The cache should be single-case, where a singleton pattern is designed:
74. private static Cacheddata Cacheddata = new Cacheddata ();
76. Private Final Readwritelock lock = new Reentrantreadwritelock (); Read/write lock
78. private map<string, object> cache = new hashmap<string, object> (); Cache
82. Private Cacheddata () {
84. }
88. public static Cacheddata getinstance () {
90. return cacheddata;
92. }
96. //Read cache:
98. Public Object Read (String key) {
100. Lock.readlock (). Lock ();
102. Object obj = null;
104. try {
106. obj = Cache.get (key);
108. if (obj = = null) {
110. Lock.readlock (). Unlock ();
112. //In this case, other threads are likely to get to the lock
114. Lock.writelock (). Lock ();
116. try {
118. if (obj = = null) {
120. obj = "Find database"; //The actual action is to find the database
122. //Update the data to the cache:
124. Cache.put (key, obj);
126. }
128. } finally {
130. //When the front thread acquires a write lock, it can get to the read lock, which is called the re-entry of the lock, and then causes the downgrade of the write lock, called the downgrade lock.
132. //The write lock can be degraded with re-entry, but only after all the write locks held by the current thread have been freed to allow the re-entry to reader to use
134. //They. So in the process of re-entry, other threads will not have the opportunity to acquire a lock (the benefit of doing so). Just think, release the write lock,
136. //Read lock, what is the disadvantage of doing this?  If you do this, you may be interrupted by another thread after you release the write lock, before you get the read lock.
138. //Re-entry ———— > Downgrade lock: Get the Write lock first, then fetch the read lock, and finally release the write lock (emphasis)
140. Lock.readlock (). Lock ();
142. Lock.writelock (). Unlock ();
144. }
146. }
148. } finally {
150. Lock.readlock (). Unlock ();
152. }
154. return obj;
156. }
158. }

Example 2:

[Java]View Plaincopy

2. Import Java.util.Map;
4. Import Java.util.TreeMap;
6. Import Java.util.concurrent.locks.Lock;
8. Import Java.util.concurrent.locks.ReadWriteLock;
10. Import Java.util.concurrent.locks.ReentrantReadWriteLock;
14. Import Javax.xml.crypto.Data;
18. /**
20. * @author amber2012
22. *
24. * A good example of the use of the Reentrantreadwritelock class in the JDK documentation, the following is a detailed description:
26. *
28. * When using certain kinds of Collection, you can use Reentrantreadwritelock to improve concurrency. Typically, the expected collection
30. * Very large, the reader thread accesses it more often than the writer thread, and the cost of the entail operation is higher than the synchronization overhead, which is worth a try. For example, the following
32. * is a class that uses TREEMAP, which is expected to be large and accessible at the same time.
34. */
36. Public class Rwdictionary {
40. Private final map<string, data> Map = new treemap<string, data> ();
42. Private final Readwritelock rwl = new Reentrantreadwritelock ();
44. Private final Lock Readlock = Rwl.readlock ();
46. Private final Lock Writelock = Rwl.writelock ();
50. Public Data Get (String key) {
52. Readlock.lock ();
54. try {
56. return Map.get (key);
58. } finally {
60. Readlock.unlock ();
62. }
64. }
68. Public string[] AllKeys () {
70. Readlock.lock ();
72. try {
74. return (string[]) Map.keyset (). ToArray ();
76. } finally {
78. Readlock.unlock ();
80. }
82. }
86. Public Data put (String key, data value) {
88. Writelock.lock ();
90. try {
92. return Map.put (key, value);
94. } finally {
96. Writelock.unlock ();
98. }
100. }
104. public void Clear () {
106. Writelock.lock ();
108. try {
110. Map.clear ();
112. } finally {
114. Writelock.unlock ();
116. }
118. }
120. }

Forwarding: Java Threads: mutexes and read-write locks