多线程基础总结八－－ReentrantReadWriteLock

核心提示： 这个例子改造自JDK的API提供的示例，其中ReadWriteLockSampleSupport辅助类负责维护一个Map，多线程基础总结八－－ReentrantReadWriteLock(2)，当然前提是这个Map大部分的多线程下都是读取，只有很少的比例是多线程竞争修改Map的值，有条件了就去狠

这个例子改造自JDK的API提供的示例，其中ReadWriteLockSampleSupport辅助类负责维护一个Map，当然前提是这个Map大部分的多线程下都是读取，只有很少的比例是多线程竞争修改Map的值。其中的initCache()简单的说明了特性(a),(b).在这个方法中如果把注释(1)和(2)处的代码调换位置，就会发现轻而易举的死锁了，当然是因为特性(1)的作用了。而注释(3)，(4)处的代码位置则再次证明了特性 (a)，并且有力的反映了特性(b)--WriteLock在cache初始化完毕之后，降级为ReadLock。另外get(),put()方法在线程获取锁之后会在方法中呆上近5s的时间。

ReentrantReadWriteLockSample中的两个静态测试方法则分别测试了ReadLock和WriteLock的排斥性。 testReadLock()中，开启三个线程，前两者试图获取ReadLock而后者去获取WriteLock。执行结果可以看到：ReadWriteLockSampleSupport的get()方法中的打印结果在前两个线程中几乎同时显示，而put()中的打印结果则要等上近5s。这就说明了，ReadLock可以多线程持有并且排斥WriteLock的持有线程。testWriteLock()中，也开启三个线程。前两个是去获取WriteLock，最后一个获取ReadLock。执行的结果是三个打印结果都有近5s的间隔时间，这说明了WriteLock是独占的，比较独！

这篇ReentrantReadWriteLock的总结写的有点迟了，主要是最近对js和ajax很有兴趣，突然觉得css也很好玩。看着网上很多人对技术的狂热和个人规划，我想对我而言：不迷恋技术而是作为兴趣，不管是J2EE还是Web前端，不管是移动设备的三方开发还是专业的视频剪辑技术，我都希望很自然的感兴趣了，有条件了就去狠狠的玩玩。我想我迷恋的只是高性能的计算机和互联网，哈哈。