• 多线程之使用读写锁ReentrantReadWriteLock实现缓存系统


    简单地缓存系统:当有线程来取数据时。假设该数据存在我的内存中。我就返回数据。假设不存在我的缓存系统中,那么就去查数据库。返回数据的同一时候保存在我的缓存中。

    当中涉及到读写问题:当多个线程运行读操作时(都加读锁)。假设有数据返回;假设没有数据时。则让第一个读的线程。进行获取数据,然后进行写操作。这时须要第一个线程先释放掉读锁然后加写锁。第一个写完后,在家读锁。其它线程使用时推断,假设存在该数据,在直接过去读取不用加写锁。

    API上缓存样例例如以下:

     class CachedData {
       Object data;
       volatile boolean cacheValid;
       ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    
       void processCachedData() {
         rwl.readLock().lock();
         if (!cacheValid) {
            // Must release read lock before acquiring write lock
            rwl.readLock().unlock();
            rwl.writeLock().lock();
            // Recheck state because another thread might have acquired
            //   write lock and changed state before we did.
            if (!cacheValid) {
              data = ...
              cacheValid = true;
            }
            // Downgrade by acquiring read lock before releasing write lock
            rwl.readLock().lock();
            rwl.writeLock().unlock(); // Unlock write, still hold read
         }
    
         use(data);
         rwl.readLock().unlock();
       }
     }
    


    ReentrantReadWriteLock

    此类具有下面属性:

    • 获取顺序

      此类不会将读取者优先或写入者优先强加给锁訪问的排序。

      可是。它确实支持可选的公平 策略。

      非公平模式(默认)
      当非公平地(默认)构造时,未指定进入读写锁的顺序,受到 reentrancy 约束的限制。连续竞争的非公平锁可能无限期地推迟一个或多个 reader 或 writer 线程,但吞吐量通常要高于公平锁。

      公平模式
      当公平地构造线程时,线程利用一个近似到达顺序的策略来争夺进入。

      当释放当前保持的锁时,能够为等待时间最长的单个 writer 线程分配写入锁,假设有一组等待时间大于全部正在等待的 writer 线程 的 reader 线程。将为该组分配写入锁。

      假设保持写入锁。或者有一个等待的 writer 线程,则试图获得公平读取锁(非重入地)的线程将会堵塞。直到当前最旧的等待 writer 线程已获得并释放了写入锁之后,该线程才会获得读取锁。当然。假设等待 writer 放弃其等待。而保留一个或很多其它 reader 线程为队列中带有写入锁自由的时间最长的 waiter,则将为那些 reader 分配读取锁。

      试图获得公平写入锁的(非重入地)的线程将会堵塞,除非读取锁和写入锁都自由(这意味着没有等待线程)。(注意,非堵塞 ReentrantReadWriteLock.ReadLock.tryLock() ReentrantReadWriteLock.WriteLock.tryLock() 方法不会遵守此公平设置,并将获得锁(假设可能),不考虑等待线程)。

    • 重入

      此锁同意 reader 和 writer 依照 ReentrantLock 的样式又一次获取读取锁或写入锁。在写入线程保持的全部写入锁都已经释放后。才同意重入 reader 使用它们。

      此外,writer 能够获取读取锁。但反过来则不成立。在其它应用程序中,当在调用或回调那些在读取锁状态下运行读取操作的方法期间保持写入锁时,重入非常实用。假设 reader 试图获取写入锁,那么将永远不会获得成功。

    • 锁降级

      重入还同意从写入锁降级为读取锁,事实上现方式是:先获取写入锁。然后获取读取锁。最后释放写入锁。可是。从读取锁升级到写入锁是不可能的

    • 锁获取的中断

      读取锁和写入锁都支持锁获取期间的中断。

    • Condition 支持

      写入锁提供了一个 Condition 实现,对于写入锁来说,该实现的行为与 ReentrantLock.newCondition() 提供的 Condition 实现对 ReentrantLock 所做的行为同样。当然,此 Condition 仅仅能用于写入锁。

      读取锁不支持 ConditionreadLock().newCondition() 会抛出 UnsupportedOperationException

    • 监測

      此类支持一些确定是保持锁还是争用锁的方法。这些方法设计用于监视系统状态,而不是同步控制。


             java实现例如以下:

         

    package andy.thread.test;
    
    import java.util.HashMap;
    import java.util.Map;
    import java.util.concurrent.locks.ReadWriteLock;
    import java.util.concurrent.locks.ReentrantReadWriteLock;
    
    /**
     * @author Zhang,Tianyou
     * @version 2014年11月9日 上午9:29:42
     */
    
    public class ThreadCaChe {
    
    	private static Map<String, Object> cacheMap = new HashMap<String, Object>();
    
    	public static void main(String[] args) {
    
    		for (int i = 0; i < 10; i++) {
    
    			new Thread(new Runnable() {
    
    				@Override
    				public void run() {
    					
    					String obj = (String) getData("andy");
    					System.out.println(obj);
    
    				}
    			}).start();
    
    		}
    
    	}
    
    
    	public static Object getData(String key) {
    		
    		ReadWriteLock rwlLock = new ReentrantReadWriteLock();
    		
    		// 先加读锁
    		rwlLock.readLock().lock();
    		Object value = null;
    		try {
    			value = cacheMap.get(key);
    			// 若不存在cache中
    			if (value == null) {
    				// 若果value为空 则释放掉读锁,让该线程获取写锁,而其它线程仅仅能等待该写锁释放,才干在进读锁
    				rwlLock.readLock().unlock();
    				// 加写锁
    				rwlLock.writeLock().lock();
    
    				try {
    					if (value == null) {
    						// 从数据中获取数据
    						value = "andy is shuai ge";// 查询数据库
    						// 存入缓存中
    						cacheMap.put(key, value);
    					}
    				} finally {
    					rwlLock.writeLock().unlock();
    				}
    
    				rwlLock.readLock().lock();
    			}
    
    		} finally {
    			// 释放第一次获取的读锁
    			rwlLock.readLock().unlock();
    		}
    
    		return value;
    	}
    }
    


    运行效果例如以下:

    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge
    andy is shuai ge


  • 相关阅读:
    Android RxJava 2.0中backpressure(背压)概念的理解
    Android 解决RecyclerView瀑布流效果结合Glide使用时图片变形的问题
    Android 滚动RecyclerView加载图片时的流畅度优化
    Android RecyclerView 滑动时图片加载的优化
    云计算之路-阿里云上:结合IIS日志分析“黑色30秒”问题团队
    云计算之路-阿里云上:对“黑色30秒”问题的猜想团队
    云计算之路-阿里云上:排查“黑色30秒”问题-为什么请求会排队团队
    云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题团队
    上周热点回顾(4.14-4.20)团队
    上周热点回顾(4.7-4.13)团队
  • 原文地址:https://www.cnblogs.com/tlnshuju/p/6824904.html
Copyright © 2020-2023  润新知