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

原文出处：http://dev.csdn.net/author/axman/4794100c5de740a09b52415cb9dd4239.html
感谢此文的作者，让我加深了理解！

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

临界区模式 Critical Section Pattern 是指在一个共享范围中只让一个线程执行的模式.
它是所有其它多线程设计模式的基础,所以我首先来介绍它.
把着眼点放在范围上,这个模式叫临界区模式,如果把作眼点放在执行的线程上,这个模式就叫
单线程执行模式.

首先我们来玩一个钻山洞的游戏,我 Axman,朋友 Sager,同事 Pentium4.三个人在八角游乐场
循环钻山洞(KAO,减肥训练啊),每个人手里有一个牌子,每钻一次洞口的老头会把当前的次序,
姓名,牌号显示出来,并检查名字与牌号是否一致.

OK,这个游戏的参与者有游乐场老头Geezer,Player,就是我们,还有山洞 corrie.

public class Geezer {
    public static void main(String[] args){
       
        System.out.println("预备,开始!");
        Corrie c = new Corrie();//只有一个山洞,所以生存一个实例后传给多个Player.
        new Player("Axman","001",c).start();
        new Player("Sager","002",c).start();
        new Player("Pentium4","003",c).start();
    }
}

这个类暂时没有什么多说的,它是一个Main的角色.

public class Player extends Thread{
    private final String name;
    private final String number;
    private final Corrie corrie;
    public Player(String name,String number,Corrie corrie) {
        this.name = name;
        this.number = number;
        this.corrie = corrie;
    }
   
    public void run(){
        while(true){
            this.corrie.into(this.name,this.number);
        }
    }
}
在这里,我们把成员字段都设成final的,为了说明一个Player一旦构造,他的名字和牌号就不能改
变,简单说在游戏中,我,Sager,Pentium4三个人不会自己偷偷把自己的牌号换了,也不会偷偷地去
钻别的山洞,如果这个游戏一旦发生错误,那么错误不在我们玩家.

import java.util.*;
public class Corrie {
    private int count = 0;
    private String name;
    private String number;
    private HashMap lib = new HashMap();//保存姓名与牌号的库
   
    public Corrie(){
       
        lib.put("Axman","001");
        lib.put("Sager","002");
        lib.put("Pentium4","003");
 
    }
   
    public void into(String name,String number){
        this.count ++;
        this.name = name;
        this.number = number;
        if(this.lib.get(name).equals(number))
 test():
    }
   
    public String display(){
        return this.count+": " + this.name + "(" + this.number + ")";
    }

    private void test(){
        if(this.lib.get(name).equals(number))
            ;
            //System.out.println("OK:" + display());
        else
            System.out.println("ERR:" + display());
    }
}
这个类中增加了一个lib的HashMap,相当于一个玩家姓名与牌号的库,因为明知道Corrie只有一个实例,
所以我用了成员对象而不是静态实例,只是为了能在构造方法中初始化库中的内容,从真正意义中说应
该在一个辅助类中实现这样的数据结构封装的功能.如果不提供这个lib,那么在check的时候就要用
if(name.equasl("Axman")){
 if(!number.equals("001")) //出错
}
else if .......
这样复杂的语句,如果player大多可能会写到手抽筋,所以用一个lib来chcek就非常容象.

运行这个程序需要有一些耐心,因为即使你的程序写得再差在很多单线程测试环境下也能可是正确的.
而且多线程程序在不同的机器上表现不同,要发现这个例子的错识,可能要运行很长一段时间,如果你的
机器是多CPU的,那么出现错误的机会就大好多.

在我的笔记本上最终出现错误是在11分钟以后,出现的错误有几钟情况:
1: ERR:Axman(003)
2: ERR:Sager(002)
第一种情况是检查到了错误,我的牌号明明是001,却打印出来003,而第二种明明没有错误,却打印了错误.

事实上根据以前介绍的多线程知识,不难理解这个例子的错误出现,因为into不是线程安全的,所以在其中
一个线程执行this.name = "Axman";后,本来应该执行this.numner="001",却被切换到另一个线程中执行
this.number="003",然后又经过不可预知的切换执行其中一个的if(this.lib.get(name).equals(number))
而出现1的错误,而在打印这个错误时因为display也不是线程安全的,正要打印一个错误的结果时,由于
this.name或this.number其中一个字段被修改却成了正确的匹配而出现错误2.

另外还有可能会出现序号颠倒或不对应,但这个错误我们无法直观地观察,因为你根本不知道哪个序号"应该"
给哪个Player,而序号颠倒则有可能被滚动的屏幕所掩盖.

[正确的Critical Section模式的例子]
我们知道出现这些错误是因为Corrie类的方法不是线程安全的,那么只要修改Corrie类为线程安全的类就行
了.其它类则不需要修改,上面说过,如果出现错误那一定不是我们玩家的事:

import java.util.*;
public class Corrie {
    private int count = 0;
    private String name;
    private String number;
    private HashMap lib = new HashMap();//保存姓名与牌号的库
   
    public Corrie(){
       
        lib.put("Axman","001");
        lib.put("Sager","002");
        lib.put("Pentium4","003");
 
    }
   
    public synchronized void into(String name,String number){
        this.count ++;
        this.name = name;
        this.number = number;
 test();
    }
   
    public synchronized String display(){
        return this.count+": " + this.name + "(" + this.number + ")";
    }

    private void test(){
        if(this.lib.get(name).equals(number))
            ;
            //System.out.println("OK:" + display());
        else
            System.out.println("ERR:" + display());
    }
}

运行这个例子,如果你的耐心,开着你的机器运行三天吧.虽然测试100天并不能说明第101天没有出错,
at least,现在的正确性比原来那个没有synchronized 保护的例子要可靠多了!

到这里我们对Critical Section模式的例程有了直观的了解,在详细解说这个模式之前,请想一下,test
方法安全吗?为什么?

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

共享资源(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等限制,另外在子类设计时也要充分考虑对父类共享资源的访问.