（9）java5的线程【锁lock】与【读写锁_以及模拟缓存(妙用)】技术

同步锁（Lock）

通常认为：Lock提供了比synchronized方法和synchronized代码块更广泛的锁定操作，Lock更灵活的结构，有很大的差别，并且可以支持多个Condition对象

Lock是控制多个线程对共享资源进行访问的工具。通常，锁提供了对共享资源的独占访问，每次只能有一个线程对Lock对象加锁，

线程开始访问共享资源之前应先获得Lock对象。不过某些锁支持共享资源的并发访问，如：ReadWriteLock（读写锁），在线程安全控制中，

通常使用ReentrantLock（可重入锁）。使用该Lock对象可以显示加锁、释放锁。



class C {

//锁对象

private final ReentrantLock lock = new ReentrantLock();

......

//保证线程安全方法

public void method() {

//上锁

lock.lock();

try {

//保证线程安全操作代码

} catch() {



} finally {

lock.unlock();//释放锁

}

}

}

使用Lock对象进行同步时，锁定和释放锁时注意把释放锁放在finally中保证一定能够执行。



使用锁和使用同步很类似，只是使用Lock时显示的调用lock方法来同步。

而使用同步方法synchronized时系统会隐式使用当前对象作为同步监视器，

同样都是“加锁->访问->释放锁”的操作模式，都可以保证只能有一个线程操作资源。



同步方法和同步代码块使用与竞争资源相关的、隐式的同步监视器，并且强制要求加锁和释放锁要出现在一个块结构中，而且获得多个锁时，

它们必须以相反的顺序释放，且必须在与所有锁被获取时相同的范围内释放所有资源。



Lock提供了同步方法和同步代码库没有的其他功能，包括用于非块结构的tryLock方法，已经试图获取可中断锁lockInterruptibly()方法，

还有获取超时失效锁的tryLock(long, timeUnit)方法。



ReentrantLock具有重入性，也就是说线程可以对它已经加锁的ReentrantLock再次加锁，



ReentrantLock对象会维持一个计数器来追踪lock方法的嵌套调用，


线程在每次调用lock()加锁后，必须显示的调用unlock()来释放锁，所以一段被保护的代码可以调用另一个被相同锁保护的方法。



JDK:



Lock 实现提供了比使用 synchronized 方法和语句可获得的更广泛的锁定操作。此实现允许更灵活的结构，可以具有差别很大的属性，可以支持多个相关的 Condition 对象。

锁是控制多个线程对共享资源进行访问的工具。通常，锁提供了对共享资源的独占访问。一次只能有一个线程获得锁，对共享资源的所有访问都需要首先获得锁。不过，某些锁可能允许对共享资源并发访问，如 ReadWriteLock 的读取锁。

synchronized 方法或语句的使用提供了对与每个对象相关的隐式监视器锁的访问，但却强制所有锁获取和释放均要出现在一个块结构中：当获取了多个锁时，它们必须以相反的顺序释放，且必须在与所有锁被获取时相同的词法范围内释放所有锁。

虽然 synchronized 方法和语句的范围机制使得使用监视器锁编程方便了很多，而且还帮助避免了很多涉及到锁的常见编程错误，但有时也需要以更为灵活的方式使用锁。例如，某些遍历并发访问的数据结果的算法要求使用 "hand-over-hand" 或 "chain locking"：获取节点 A 的锁，然后再获取节点 B 的锁，然后释放 A 并获取 C，然后释放 B 并获取 D，依此类推。Lock 接口的实现允许锁在不同的作用范围内获取和释放，并允许以任何顺序获取和释放多个锁，从而支持使用这种技术。

随着灵活性的增加，也带来了更多的责任。不使用块结构锁就失去了使用 synchronized 方法和语句时会出现的锁自动释放功能。在大多数情况下，应该使用以下语句：

Lock l = ...;

l.lock();

try {

// access the resource protected by this lock

} finally {

l.unlock();

}



锁定和取消锁定出现在不同作用范围中时，必须谨慎地确保保持锁定时所执行的所有代码用 try-finally 或 try-catch 加以保护，以确保在必要时释放锁。

Lock 实现提供了使用 synchronized 方法和语句所没有的其他功能，包括提供了一个非块结构的获取锁尝试 (tryLock())、一个获取可中断锁的尝试 (lockInterruptibly()) 和一个获取超时失效锁的尝试 (tryLock(long, TimeUnit))。

Lock 类还可以提供与隐式监视器锁完全不同的行为和语义，如保证排序、非重入用法或死锁检测。如果某个实现提供了这样特殊的语义，则该实现必须对这些语义加以记录。

注意，Lock 实例只是普通的对象，其本身可以在 synchronized 语句中作为目标使用。获取 Lock 实例的监视器锁与调用该实例的任何 lock() 方法没有特别的关系。为了避免混淆，建议除了在其自身的实现中之外，决不要以这种方式使用 Lock 实例。

除非另有说明，否则为任何参数传递 null 值都将导致抛出 NullPointerException。

内存同步

所有 Lock 实现都必须 实施与内置监视器锁提供的相同内存同步语义，如 The Java Language Specification, Third Edition (17.4 Memory Model) 中所描述的:

成功的 lock 操作与成功的 Lock 操作具有同样的内存同步效应。

成功的 unlock 操作与成功的 Unlock 操作具有同样的内存同步效应。

不成功的锁定与取消锁定操作以及重入锁定/取消锁定操作都不需要任何内存同步效果。

实现注意事项

三种形式的锁获取（可中断、不可中断和定时）在其性能特征、排序保证或其他实现质量上可能会有所不同。而且，对于给定的 Lock 类，可能没有中断正在进行的 锁获取的能力。因此，并不要求实现为所有三种形式的锁获取定义相同的保证或语义，也不要求其支持中断正在进行的锁获取。实现必需清楚地对每个锁定方法所提供的语义和保证进行记录。还必须遵守此接口中定义的中断语义，以便为锁获取中断提供支持：完全支持中断，或仅在进入方法时支持中断。


由于中断通常意味着取消，而通常又很少进行中断检查，因此，相对于普通方法返回而言，实现可能更喜欢响应某个中断。即使出现在另一个操作后的中断可能会释放线程锁时也是如此。实现应记录此行为。

package com.itm.thread;

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class LockTest {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		
		 new LockTest().init();
	}
	private void init(){
		final Outputer outputer = new Outputer();//这个家伙一定要找一个外部类，也就是 谁调用了 init()方法。
		  
			new Thread(new Runnable(){
 				@Override 
 				 public void run() { 
 				
 					while(true){ 
 						try { 
 								Thread.sleep(1000);
 							}catch (InterruptedException e) { 
 								e.printStackTrace(); 
 						}
 						outputer.output("zhangxiaoxiang"); 
				
 					} 
 				} 
			}).start();
			
			new Thread(new Runnable(){
 				@Override 
 				 public void run() { 
 				
 					while(true){ 
 						try { 
 								Thread.sleep(1000);
 							}catch (InterruptedException e) { 
 								e.printStackTrace(); 
 						}
 						outputer.output("lihuoming");
 						
				
 					} 
 				} 
			}).start();
	}

	static class Outputer {
		Lock lock = new ReentrantLock();
		public void output(String name) {
			int len = name.length();
			lock.lock();
				try{
					for (int i = 0; i < len; i++) {
						System.out.print(name.charAt(i));
					}
					System.out.println();// 此句为 换行。
				}finally{
					lock.unlock();
				}
		}
	}
}

读写锁：

public interface ReadWriteLock

ReadWriteLock 维护了一对相关的

锁

，一个用于只读操作，另一个用于写入操作。只要没有 writer，

读取锁

可以由多个 reader 线程同时保持。

写入锁

是独占的。

所有 ReadWriteLock 实现都必须保证writeLock 操作的内存同步效果也要保持与相关readLock 的联系。也就是说，成功获取读锁的线程会看到写入锁之前版本所做的所有更新。

与互斥锁相比，读-写锁允许对共享数据进行更高级别的并发访问。虽然一次只有一个线程（writer 线程）可以修改共享数据，但在许多情况下，任何数量的线程可以同时读取共享数据（reader 线程），读-写锁利用了这一点。从理论上讲，与互斥锁相比，使用读-写锁所允许的并发性增强将带来更大的性能提高。在实践中，只有在多处理器上并且只在访问模式适用于共享数据时，才能完全实现并发性增强。

与互斥锁相比，使用读-写锁能否提升性能则取决于读写操作期间读取数据相对于修改数据的频率，以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数。例如，某个最初用数据填充并且之后不经常对其进行修改的 collection，因为经常对其进行搜索（比如搜索某种目录），所以这样的 collection 是使用读-写锁的理想候选者。但是，如果数据更新变得频繁，数据在大部分时间都被独占锁，这时，就算存在并发性增强，也是微不足道的。更进一步地说，如果读取操作所用时间太短，则读-写锁实现（它本身就比互斥锁复杂）的开销将成为主要的执行成本，在许多读-写锁实现仍然通过一小段代码将所有线程序列化时更是如此。最终，只有通过分析和测量，才能确定应用程序是否适合使用读-写锁。

尽管读-写锁的基本操作是直截了当的，但实现仍然必须作出许多决策，这些决策可能会影响给定应用程序中读-写锁的效果。这些策略的例子包括：

在 writer 释放写入锁时，reader 和 writer 都处于等待状态，在这时要确定是授予读取锁还是授予写入锁。Writer 优先比较普遍，因为预期写入所需的时间较短并且不那么频繁。Reader 优先不太普遍，因为如果 reader 正如预期的那样频繁和持久，那么它将导致对于写入操作来说较长的时延。公平或者“按次序”实现也是有可能的。
在 reader 处于活动状态而 writer 处于等待状态时，确定是否向请求读取锁的 reader 授予读取锁。Reader 优先会无限期地延迟 writer，而 writer 优先会减少可能的并发。
确定是否重新进入锁：可以使用带有写入锁的线程重新获取它吗？可以在保持写入锁的同时获取读取锁吗？可以重新进入写入锁本身吗？
可以将写入锁在不允许其他 writer 干涉的情况下降级为读取锁吗？可以优先于其他等待的 reader 或 writer 将读取锁升级为写入锁吗？

当评估给定实现是否适合您的应用程序时，应该考虑所有这些情况。

readLock
Lock readLock()返回用于读取操作的锁。 

返回：
用于读取操作的锁。

--------------------------------------------------------------------------------

writeLock
Lock writeLock()返回用于写入操作的锁。 

返回：
用于写入操作的锁。

读写锁实例：

package com.itm.thread;

/*
 * 
 * java5中新增了线程锁的功能，即Lock，作用于synchronized修饰符相同。

 	都是确保作用范围的代码在执行时其他线程不能进入。
 	
 	读写锁ReadWriteLock拥有更加强大的功能，它可以细分为读锁和谢锁。
 
 	读锁可以允许多个进行读操作的线程同时进入，但不允许写进程进入；
 	
 	写锁只允许一个写进程进入，在这期间任何进程都不能再进入。
 	
 	要注意的是每个读写锁都有挂锁和解锁，最好将每一对挂锁和解锁操作都用try、finally来套入中间的代码，这样就会防止因异常的发生而造成死锁得情况。
 	下面是一个示例程序：
 
 */
import java.util.Random;
import java.util.concurrent.locks.*;

public class ReadWriteLockTest {
	public static void main(String[] args) {
		final TheData myData = new TheData(); // 这是各线程的共享数据
		for (int i = 0; i < 3; i++) { // 开启3个读线程
			new Thread(new Runnable() {
				@Override
				public void run() {
					while (true) {
						myData.get();
					}
				}
			}).start();
		}
		for (int i = 0; i < 3; i++) { // 开启3个写线程
			new Thread(new Runnable() {
				@Override
				public void run() {
					while (true) {
						myData.put(new Random().nextInt(10000));
					}
				}
			}).start();
		}
	}
}

class TheData {
	private Object data = null;
	private ReadWriteLock rwl = new ReentrantReadWriteLock();

	public void get() {
		rwl.readLock().lock(); // 读锁开启，读线程均可进入
		try { // 用try finally来防止因异常而造成的死锁
			System.out.println(Thread.currentThread().getName()
					+ "is ready to read");
			Thread.sleep(new Random().nextInt(100));
			System.out.println(Thread.currentThread().getName()
					+ "have read date" + data);
		} catch (InterruptedException e) {
			e.printStackTrace();
		} finally {
			rwl.readLock().unlock(); // 读锁解锁
		}
	}

	public void put(Object data) {
		rwl.writeLock().lock(); // 写锁开启，这时只有一个写线程进入
		try {
			System.out.println(Thread.currentThread().getName()
					+ "is ready to write");
			Thread.sleep(new Random().nextInt(100));
			this.data = data;
			System.out.println(Thread.currentThread().getName()
					+ "have write date" + data);
		} catch (InterruptedException e) {
			e.printStackTrace();
		} finally {
			rwl.writeLock().unlock(); // 写锁解锁
		}
	}
}

读写锁模拟缓存机制

/*
	 
	 
	 
	 java.util.concurrent.locks 

	类 ReentrantReadWriteLock
	java.lang.Object
	  java.util.concurrent.locks.ReentrantReadWriteLock
	所有已实现的接口： 
	Serializable, ReadWriteLock 

	//--------------------------------------------------------------------------------

	public class ReentrantReadWriteLockextends Objectimplements ReadWriteLock, Serializable支持与 ReentrantLock 类似语义的 ReadWriteLock 实现。 

	此类具有以下属性： 

	获取顺序 
	   此类不会将读取者优先或写入者优先强加给锁访问的排序。但是，它确实支持可选的公平 策略。 

	非公平模式（默认） 
	  当非公平地（默认）构造时，未指定进入读写锁的顺序，受到 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 只能用于写入锁。 

	读取锁不支持 Condition，readLock().newCondition() 会抛出 UnsupportedOperationException。 

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

	此类行为的序列化方式与内置锁的相同：反序列化的锁处于解除锁状态，无论序列化该锁时其状态如何。 

	示例用法。下面的代码展示了如何利用重入来执行升级缓存后的锁降级（为简单起见，省略了异常处理）： 
	
	*/

	 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();
	   }
	 }
	 /*在使用某些种类的 Collection 时，可以使用 ReentrantReadWriteLock 来提高并发性。
	     通常，在预期 collection 很大，读取者线程访问它的次数多于写入者线程,
	       并且 entail 操作的开销高于同步开销时，这很值得一试。
	       例如，以下是一个使用 TreeMap 的类，预期它很大，并且能被同时访问。 */
	 
	class RWDictionary {
	    private final Map<String, Data> m = new TreeMap<String, Data>();
	    private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
	    private final Lock r = rwl.readLock();
	    private final Lock w = rwl.writeLock();

	    public Data get(String key) {
	        r.lock();
	        try { return m.get(key); }
	        finally { r.unlock(); }
	    }
	    public String[] allKeys() {
	        r.lock();
	        try { 
	        	return (String[]) m.keySet().toArray(); 
	        	}finally { 
	        		r.unlock(); 
	        	}
	    }
	    public Data put(String key, Data value) {
	        w.lock();
	        try { return m.put(key, value); }
	        finally { w.unlock(); }
	    }
	    public void clear() {
	        w.lock();
	        try { m.clear(); }
	        finally { w.unlock(); }
	    }
	 }
	/* 
	 实现注意事项：
	此锁最多支持 65535 个递归写入锁和 65535 个读取锁。试图超出这些限制将导致锁方法抛出 Error。
*/

读写锁 实现缓存机制

package com.itm.thread;

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

public class CacheDemo {

	private Map<String,Object> cache = new HashMap<String,Object>();
	
	public static void main(String[] args) {
		

	}
	
	/*public synchronized Object getData(String key){
		Object value = cache.get(key);
		if(value == null){
			value = "aaa"; // 实际是  queryDB();
		}
		return null;
	}
	 */
	private ReadWriteLock rwl = new ReentrantReadWriteLock();
	public Object getData(String key){
		rwl.readLock().lock();
		Object value = null;
		try{
			value = cache.get(key);
			if(value == null){
				// 如果发现 为 null，就把 读锁 释放。
				rwl.readLock().unlock();
				// 接着  加上一把  Writer 锁。
				rwl.writeLock().lock();
				try{
					/*******
					 * 
					 *  还是要判断一下 ，因为 有多个锁  第一个Writer锁，上好了  后面的锁 就要看情况了。
					 * 
					 * 
					 */
					if(value == null){
						value = "aaa"; // 实际是  queryDB();
					}
				}finally{
					// 读到数据就释放。
					rwl.writeLock().unlock();
				}
				// 恢复  我的  read锁。
				rwl.readLock().lock();
			}
		}finally{
			rwl.readLock().unlock();
		}
		return value;
	}
}

修改整理后：

package com.itm.thread;

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/*****
 * 
 * 缓存是指存放一些常用数据的空间，程序在查找数据时会先从缓存中查找,
 * 在没找到的情况下才会去数据库中查找，当然这样速度比直接从缓存获取要满很多。
 * 
 * @author 
 *
 */
public class CacheDemo {

	private Map<String,Object> cache = new HashMap<String,Object>();
	
	public static void main(String[] args) {
		

	}
	private ReadWriteLock rwl = new ReentrantReadWriteLock();
	public Object getData(String key){
		
		//(1)开启读锁，读线程都可以进入。(2)先从缓存中去取数据,先加上读锁。
		rwl.readLock().lock();
		Object value = null;
		try{
			value = cache.get(key); //根据关键字在查找cache中查找。。从缓存中去取数据
			
			if(value == null){ // 当在cache中无法找到时关闭读锁，开启写锁。
				 //先解除读锁，再上写锁(必须先解除读锁才能成功上写锁)   如果发现 为 null，就把 读锁 释放。
				rwl.readLock().unlock();
				// 接着  加上一把  Writer 锁。
				rwl.writeLock().lock(); // 这样就只有一个写线程进入
				
				//去数据库取数据,再判断一次是否为null，因为有可能多个线程获得写锁   
				try{
					
					/**
					  	还是要判断一下 ，因为 有多个锁  第一个Writer锁，上好了  后面的锁 就要看情况了。
					
					 */
					if(value == null){
						value = "aaa"; // 实际是  queryDB();
					}
				}finally{
					// 读到数据就释放。(2)操作完后写锁关闭..
					rwl.writeLock().unlock();
				}
				// 恢复  我的  read锁。(2)读锁开启，为了与最后的读锁关闭相对应
				rwl.readLock().lock();
			}
		}finally{
			rwl.readLock().unlock();
		}
		return value;
	}
}