一道面试题比较synchronized和读写锁_JAVA_编程开发_程序员俱乐部

一、科普定义

这篇博文的两个主角“synchronized”和“读写锁”

1）synchronized

这个同步关键字相信大家都用得比较多，在上一篇“多个线程之间共享数据的方式”中也详细列举他的应用，在这就不多说只做几点归纳：

• Java提供这个关键字，为防止资源冲突提供的内置支持。当任务执行到被synchronized保护的代码片段的时候，它检查锁是否可用，然后获取锁，执行代码，释放锁。
• 常用这个关键字可以修饰成员方法和代码块

2）读写锁

我们对数据的操作无非两种：“读”和“写”，试想一个这样的情景，当十个线程同时读取某个数据时，这个操作应不应该加同步。答案是没必要的。只有以下两种情况需要加同步：

• 这十个线程对这个公共数据既有读又有写
• 这十个线程对公共数据进行写操作
• 以上两点归结起来就一点就是有对数据进行改变的操作就需要同步

所以

class="java" name="code">public synchronized Object getData(String key){
		Object result = map.get(key);
		if(result ==null){
			result = "new";//用这步代替访问数据库得数据
		}
		return result;
		
}

public Object getData(String key){
		rw.readLock().lock();//在读前先上读锁
		Object result = null;
		try{
			result = map.get(key);
                        //这个if比较关键，它避免了多余的几次对数据哭的读取
			if(result==null){
				//如果内存中没有所要数据
				rw.readLock().unlock();
				rw.writeLock().lock();
				if(result==null){
					try{
					   //我们用这个代替对数据库访问得到数据的步骤	
                                            result = "new";
					}finally{
					rw.writeLock().unlock();
					}
					rw.readLock().lock();
				}
			}
		}finally{
			rw.readLock().unlock();
		}
		return result;
		
	}

1. 用第一种方法处理，整个过程比较粗线条，代码比较简单单执行效率很低。这种方法的中心思想是不管你是什么操作，但凡涉及到公共资源就都给你同步。这么做可以是可以但是并不好。
2. 第二种用读写锁处理显然是对前者的一个优化，对第二种方法做如下几点说明：

• 关于unlock操作，我们知道只要是上了锁就必须要解锁，但是有这么一种情况就是当你上完锁后在执行解锁操作前程序出现异常，那这个所可能就一直存在。所以针对这个问题我们一般将unlock操作放在finally代码块中，就可以保证上了的锁一定会被解。
• 上面的两次if判断，第一个if相信大家很好理解。但为什么要用第二个if呢？再假设一个场景，现在有十个线程来读这个数据，而这个数据又不存在与缓存区，那么这十个线程中最先到的线程将执行“rw.writeLock().lock();”而另外九个线程将被阻塞，当第一个线程读完以后缓存区实际上已经就有了这个数据，但另外九个阻塞在“rw.writeLock().lock();”如果不加这层if他们会继续访问数据库，由此可见加了这层if对整个过程影响很大。这是比较细节的一点，就这一点Java的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();
   }
 }

?学习在继续！！！Go!Go!Go!!!

?

?

?