多线程编程的设计模式 临界区模式(二)

所谓模式就是脱离特定的例子使用更一般化的,通用化的表达方式来察看,描述,总结相同的问题.现在
我们来研究这个模式:

共享资源(sharedResource)参与者:
在临界区模式中,一定有一个或一个以上的共享资源角色的参与.在上面这个例子中就是山洞(Corrie).

共享资源参与者会被多个线程访问,这个角色的访问方法有两种类型,一种是多个线程访问也不会发生问
题的方法,称为线程安全的方法,另一种就是在多个线程同时访问时会发生问题需要保护的方法,称为不安
全的方法.


这里所说的线程安全和不安全的方法,不用多说大家都知道是指公开的方法.对上节最后我留下的问题而
言,test方法是安全的,因为它是private的,只会被into方法调用,而into方法是同步的,简单说test中的
代码一定会在同步块中执行,而display方法是public的,有可能被任何线程调用,所以它需要同步.

对于线程安全的方法,不需要多说.而对于不安全的方法,只要定义为synchronized的就可以达到保护的
目的.也就是多个线程同时执行该段代码时,只有一个线程有机会执行,具体机制我们在多线程中同步对象
锁中已经说明过.我们把这种只有一个线程能进入的程序范围,称为[临界区]


尽管JDK5以后提供了很多功能更强,语义更准确的并发控制的接口供程序员调用,但我还是极力推荐在大
多数情况下(除非需要有效的控制)还是使用synchronized来保护临界区,因为synchronized块的开始和结
束是自动控制的,在离开同步块时会自动释放同步对象锁.而使用java的lock对象时,你不得不每时每刻小
心地在finally从句中调用lock对象的unlock方法,这比在finally从句中释放数据库连结更重要!

[适用环境]

1.单线程环境:单线程环境中肯定只有一个线程执行,无论是否在临界区中反正只有一个线程执行,所以没
有必要用synchronized保护,当然如果你非想用synchronized保护没有问题,只是会引起性能的降低,但不
会降低太大.这就象一个人在家里已经关上了大门,还关着卧室的小门,除了会给你带来一些不便之处,没有
什么太大的损失.

2.多线程环境:如果这些多线程环境中各自完全独立地运行,当然没有问题.但如果多个线程可能访问同一
SharedResource对象时,就需要使用临界区模式来保护.有时管理线程的环境会提供一种SafeThread环境来
确保线程的独立,这种情况就不需要使用临界区模式.

3.SharedResource的状态会发生改变的情况才需要使用这个模式,如果SharedResource对象一经生成就不
会改变,当然不需要保护.(只读模式)

4.在必要的确保安全性的时候使用这个模式.比如java数据结构类大多数都不是线程安全的.因为很多情况
下发生多个线程共享冲突对程序本身并无大碍,比如用一个ArrayList或HashMap存放在线人数,对于在线
人数这种数据本来就不可能精确地计算,只是相对时间内的一个概数,所以多个线程访问对产生冲突对其几
乎没有影响.
但是对于需要确保线程安全的时候,java仍然提供了大量的线程安全的数据结构的封装,由Collections类
提供的synchronizedXXX()方法可以将传入的数据结构封装为线程安全的.


[性能因素]
在程序设计中,大多数情况下,各种优点无法共存,事实上如果使用一个模式能给其它方面的优点也带来提
升那简单就没有理由不使用该模式了.对于安全性的提升往往要以牺牲性能为代价,所以临界区模式会带来
一些性能方面的损失.如何权衡这它们之间的比例,要看程序运行的环境,目的等各方面的因素.

1.获取对象锁的操作本身是要花时间的.一个线程在获取同步对象锁时,其实就是一个全局对象的自旋锁,这
个全局对象是要注册到线程管理系统中的.这个过程本身需要一定的时间.但这个过程性能影响并不大.

2.同步对象锁被其它线程占用时需要等待.当一个线程进入同步块时,获取该同步对象的锁,如果该锁被其它
线程拥有测当前线程必须等待,从而降低性能,这方面性能的降低较大.

提高性能的方法一是尽量减少共享资源的数量.二是尽量减小临界区的范围.双检锁模式就是减小临界区范

围的一种手段.

[死锁问题]
临界区模式中非常重要的一点是多线程程序的生命指数.再安全的程序如果运行一定时间就结束自己的生命
而不能继续运行,那就根本不能达到设计的目的.除去系统突发因素,影响生命指数的最大原因就是死锁.
对于大家都熟悉的五个哲学家(好象是故意调侃哲学家)吃面条的例子,我们用最简单的模型简单为两个哲学
家.然后从中抽象出死锁的最一般的条件:

1.有多个共享资源被多线程共享.对于两个吃面的哲学家而言就是刀和叉两上以上的共享资源.

2.对一个共享资源的占用还没有释放锁又获取另一个共享资源.占用了刀的时候又要获取叉.

3.对共享资源的占用顺序是不固定的.如果哲学家按一定顺序使用刀和叉,一个用完了思考时再让给另一个
用那就能很好地完成目标而不会发生死锁,正时因为对共享资源占用的顺序是无法确定的.当一个结程占用
一个共享资源时,要获取另一个线程占用的共享资源,而另一个线程释放这个共享资源的条件是以获取被原
先被占用的共享资源时,才会发生死锁.

所以如果我们破坏上面其中之一的条件就不会发生死锁问题,也就是在设计时要考虑不要同时发生上面的
三程情况.

[嵌套锁定]
对于同一对象的嵌套锁定,例子如下:
synchronized(this){//1
    System.out.println("outter");
    synchronized(this){//2
        System.out.println("inner");
    }
}
这个例子能运行吗?答案是可以很好地运行.
一般以为线程运行到1时,获取了当前对象锁,打印outter后,运行到2,又要获取当前对象锁,而此时当前对象
锁还没有释放,所以线程一直等在这儿发生死锁.
其实java是一种smart language,在编译的时候,它就会检查对同一对象的嵌套锁定.因为不可能发生在层同
步块中有多个线程进入而其中一个线程要进入内层同步块的情况,也就是外层同步块本身就可以保证只有一
个线程获取同步对象的锁,所以内层同一对象的同步块在编译的时候已经失去它的作用.

[继承和扩展]
对于临界区模式而言,即使我们已经使用synchronized方法对共享资源进行保护,但是子类在扩展接口时很可
能将共享资源以不安全方式暴露出去.这是非常值得注意的问题.设计时应该尽时将对共享资源的访问方法加
以保护,可以使用private和final等限制,另外在子类设计时也要充分考虑对父类共享资源的访问.