一道面试题比较synchronized和读写锁-编程开发技术

《一道面试题比较synchronized和读写锁-编程开发技术》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

1、-道面试题比较synchronized和读写锁・编程开发技术—道面试题比较synchronized和读写锁原文出处：where一、科普定义这篇博文的两个主角“synchronized”和“读写锁”1)synchronized这个同步关键字相信大家都用得比较多，在上一篇“多个线程之间共享数据的方式”中也详细列举他的应用，在这就不多说只做几点归纳：•Java提供这个关键字，为防止资源冲突提供的内置支持。当任务执行到被synchronized保护的代码片段的时候，它检查锁是否可用，然后获取锁，执行代码,释放锁。•常用这个关键字可以修饰成员方法和代码块2)读写锁我们对数据的操作无非两种：“读”和

2、“写”，试想一个这样的情景，当十个线程同时读取某个数据时，这个操作应不应该加同步。答案是没必要的。只有以下两种情况需要加同步：•这十个线程对这个公共数据既有读乂有写•这十个线程对公共数据进行写操作•以上两点归结起来就一点就是有对数据进行改变的操作就需要同步所以java5提供了读写锁这种锁支持多线程读操作不互斥，多线程读写互斥，多线程写写互斥。读操作不互斥这样有助于性能的提高，这点在java5以前没有二.用一道面试题来具体比较这两点题目：“口板编程，实现一个缓存系统"题目分析：对这个缓存系统的理解：间于用户和数据库屮间的一个环节，我们知道用户宜接访问数据库的时间是远人于肓接访问内存，所以有

3、了缓存区后用八访问数据时?这样，用八先访问缓存区当缓存区有用八需要的数据吋直接拿走，当缓存区没有这样的数据，访问数据库并把访问所得的数据放在缓存区,这样当下一个需耍这个数据的用户就直接访问内存即可得到。核心代码实现：首先用synchronized实现publicsynchronizedObjectgetData(Stringkey){Objectresult二map.get(key);if(resuIt二二null){result二〃new〃;//用这步代替访问数据库得数据}returnresult;)用读写锁实现publicObjectgetData(Stringkey){rw.rea

4、dLock().lock();//在读前先上读锁Objectresult二nul1;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.readLo

5、ck().unlock();}returnresult;?代码分析:1.用第一种方法处理，整个过程比较粗线条，代码比较简单单执行效率很低。这种方法的中心思想是不管你是什么操作，但凡涉及到公共资源就都给你同步。这么做可以是可以但是并不好。1.第二种用读写锁处理显然是对前•者的一个优化，对第二种方法做如下几点说明：•关于unlock操作，我们知道只要是上了锁就必须要解锁，但是有这么一种情况就是当你上完锁后在执行解锁操作前程序出现杲常，那这个所可能就一直存在。所以针对这个问题我们一般将unlock操作放在finally代码块屮，就可以保证上了的锁一定会被解。•上而的两次if判断，笫一个if相信

6、大家很好理解。但为什么耍用第二个if呢？再假设一个场景，现在冇十个线程来读这个数据，而这个数据又不存在与缓存区，那么这十个线程中最先到的线程将执行“rw・writeLock()・lock();”而另外九个线程将被阻塞，当第一个线程读完以后缓存区实际上己经就冇了这个数据，但另外九个阻塞在t4rw.writeLock().lock()r如果不加这层if他们会继续访问数据库,由此可见加了这层if对整个过程影响很大。这是比较细节的一点，就这一点Java的API文档也考虑到了，它的样例代码如下：classCachcdData{Objectdata;volatilebooleancacheValid

7、;ReentrantReadWriteLockrwl二newReentrantReadWriteLock();voidproccssCachcdData(){rwl.readLock()・lock();if(!cacheValid){//Mustreleasereadlockbeforeacquiringwritelockrwl.readLock().unlock