Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to realize and think about the read-write lock algorithm in Java

2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article is about the Java implementation of the read-write lock algorithm and how to think about it. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it.

Problem background: multiple threads read and write access to a shared resource. The writer thread needs to be mutually exclusive, the reader thread and the writer thread need to be mutually exclusive, and the reader thread does not need mutual exclusion.

Earlier, I listened to a lesson from sir about the enhanced concurrency features in java5. The problem of read-write lock can be easily solved by using ReadWriteLock in java.util.concurrent.locks. I was thinking, if there is no ReadWriteLock, how can synchronized alone do? Indeed, it's troublesome.

1. Combined with the object-oriented design idea taught by Zhang sir, firstly, a business class Business is designed as a shared resource, encapsulating write and read methods.

two。 Because write must be mutually exclusive, define synchronized directly.

There is no mutual exclusion between 3.read, so read cannot define synchronized directly, but write and read need mutual exclusion. One way that I can think of is to add synchronized (this) {} to read and define readThreads counters as semaphores. I imagine the following situations will occur:

Read [m] represents the read method of a thread.

Write [n] ditto

When synchronized (this) {readThreads++;} is executed in 1 > read [m], write [n] arrives and write [n] is blocked by its own synchronized.

2 > read [m] when do something (there is no lock at this time), write [n] comes and is forced to wait because of readThreads instead of 0.

3 > write [n] in wait is notify every time READM ends, but write [n] has no choice but to wait again if other read is found.

4 > when readThreads==0 and notifyAll are called, read [m] and write [n] will compete for cpu. If write [n] loses again, 1 > or 3 > will appear. If it is successful, it will be as follows:

5 > if write [n] wait wakes up to occupy the lock, read [m] is blocked on synchronized (this) {readThreads++;}.

6 > if blocked write [n] occupies the lock, read [m] is blocked on top of synchronized (this) {readThreads++;}.

From the above, read and write are mutually exclusive.

4. The implementation details are as follows:

Package communication; import java.util.Random; public class ReadWriteLockTest {public static void main (String [] args) {final Business business = new Business (); / / start 4 threads 2 read and write for (int iThreads 1)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report