数据库大并发操作要考虑死锁和锁的性能问题。看到网上大多语焉不详(尤其更新锁），所以这里做个简明解释，为下面描述方便，这里用T1代表一个数据库执行请求，T2代表另一个请求，也可以理解为T1为一个线程，T2 为另一个线程。T3,T4以此类推。下面以SQL Server(2005)为例。

1. 共享锁(Shared lock)。

   例1：
   ----------------------------------------
   T1:    select * from table (请想象它需要执行1个小时之久，后面的sql语句请都这么想象）
   T2:    update table set column1='hello'
   
   过程：
   
   T1运行 （加共享锁)
   T2运行
   If T1 还没执行完
       T2等......
   else
       锁被释放
       T2执行
   endif
   
   T2之所以要等，是因为T2在执行update前，试图对table表加一个排他锁，
   而数据库规定同一资源上不能同时共存共享锁和排他锁。所以T2必须等T1
   执行完，释放了共享锁，才能加上排他锁，然后才能开始执行update语句。
   
   例2：
   ----------------------------------------
   T1:    select * from table
   T2:    select * from table
   
   这里T2不用等待T1执行完，而是可以马上执行。
   
   分析：
   T1运行，则table被加锁，比如叫lockA
   T2运行，再对table加一个共享锁，比如叫lockB。
   
   两个锁是可以同时存在于同一资源上的（比如同一个表上）。这被称为共
   享锁与共享锁兼容。这意味着共享锁不阻止其它session同时读资源，但阻
   止其它session update
   
   例3：
   ----------------------------------------
   T1:    select * from table
   T2:    select * from table
   T3:    update table set column1='hello'
   
   这次，T2不用等T1运行完就能运行，T3却要等T1和T2都运行完才能运行。
   因为T3必须等T1和T2的共享锁全部释放才能进行加排他锁然后执行update
   操作。
   
   例4：（死锁的发生）
   ----------------------------------------
   T1:
   begin tran
   select * from table (holdlock) (holdlock意思是加共享锁，直到事物结束才释放)
   update table set column1='hello'
   
   T2:
   begin tran
   select * from table(holdlock)
   update table set column1='world'
   
   假设T1和T2同时达到select，T1对table加共享锁，T2也对加共享锁，当
   T1的select执行完，准备执行update时，根据锁机制，T1的共享锁需要升
   级到排他锁才能执行接下来的update.在升级排他锁前，必须等table上的
   其它共享锁释放，但因为holdlock这样的共享锁只有等事务结束后才释放，
   所以因为T2的共享锁不释放而导致T1等(等T2释放共享锁，自己好升级成排
   他锁），同理，也因为T1的共享锁不释放而导致T2等。死锁产生了。
   
   例5：
   ----------------------------------------
   T1:
   begin tran
   update table set column1='hello' where id=10
   
   T2:
   begin tran
   update table set column1='world' where id=20
   
   这种语句虽然最为常见，很多人觉得它有机会产生死锁，但实际上要看情
   况，如果id是主键上面有索引，那么T1会一下子找到该条记录(id=10的记
   录），然后对该条记录加排他锁，T2，同样，一下子通过索引定位到记录，
   然后对id=20的记录加排他锁，这样T1和T2各更新各的，互不影响。T2也不
   需要等。
   
   但如果id是普通的一列，没有索引。那么当T1对id=10这一行加排他锁后，
   T2为了找到id=20，需要对全表扫描，那么就会预先对表加上共享锁或更新
   锁或排他锁(依赖于数据库执行策略和方式，比如第一次执行和第二次执行
   数据库执行策略就会不同）。但因为T1已经为一条记录加了排他锁，导致
   T2的全表扫描进行不下去，就导致T2等待。
   
   死锁怎么解决呢？一种办法是，如下：
   例6：
   ----------------------------------------
   T1:
   begin tran
   select * from table(xlock) (xlock意思是直接对表加排他锁)
   update table set column1='hello'
   
   T2:
   begin tran
   select * from table(xlock)
   update table set column1='world'
   
   这样，当T1的select 执行时，直接对表加上了排他锁，T2在执行select时，就需要等T1事物完全执行完才能执行。排除了死锁发生。
   但当第三个user过来想执行一个查询语句时，也因为排他锁的存在而不得不等待，第四个、第五个user也会因此而等待。在大并发
   情况下，让大家等待显得性能就太友好了，所以，这里引入了更新锁。

2. 更新锁(Update lock)

   为解决死锁，引入更新锁。
   
   例7：
   ----------------------------------------
   T1:
   begin tran
   select * from table(updlock) (加更新锁)
   update table set column1='hello'
   T2:
   begin tran
   select * from table(updlock)
   update table set column1='world'
   
   更新锁的意思是：“我现在只想读，你们别人也可以读，但我将来可能会做更新操作，我已经获取了从共享锁（用来读）到排他锁
   （用来更新）的资格”。一个事物只能有一个更新锁获此资格。
   
   T1执行select，加更新锁。
   T2运行，准备加更新锁，但发现已经有一个更新锁在那儿了，只好等。
   
   当后来有user3、user4...需要查询table表中的数据时，并不会因为T1的select在执行就被阻塞，照样能查询，相比起例6，这提高
   了效率。
   
   例8:
   ----------------------------------------
   T1:    select * from table(updlock)    (加更新锁）
   T2:    select * from table(updlock)    (等待，直到T1释放更新锁，因为同一时间不能在同一资源上有两个更新锁）
   T3:    select * from table (加共享锁，但不用等updlock释放，就可以读）
   
   这个例子是说明：共享锁和更新锁可以同时在同一个资源上。这被称为共享锁和更新锁是兼容的。
   
   例9:
   ----------------------------------------
   T1:
   begin
   select * from table(updlock)      (加更新锁）
   update table set column1='hello'  (重点：这里T1做update时，不需要等T2释放什么，而是直接把更新锁升级为排他锁，然后执行update)
   T2:
   begin
   select * from table               (T1加的更新锁不影响T2读取）
   update table set column1='world'  (T2的update需要等T1的update做完才能执行)
   
   我们以这个例子来加深更新锁的理解，
   
   第一种情况：T1先达，T2紧接到达；在这种情况中，T1先对表加更新锁，T2对表加共享锁，假设T2的select先执行完，准备执行update，
   发现已有更新锁存在，T2等。T1执行这时才执行完select，准备执行update，更新锁升级为排他锁，然后执行update，执行完成，事务
   结束，释放锁，T2才轮到执行update。
   
   第二种情况：T2先达，T1紧接达；在这种情况，T2先对表加共享锁，T1达后，T1对表加更新锁，假设T2 select先结束，准备
   update，发现已有更新锁，则等待，后面步骤就跟第一种情况一样了。
   
   这个例子是说明：排他锁与更新锁是不兼容的，它们不能同时加在同一子资源上。

3. 排他锁（独占锁，Exclusive Locks)

   这个简单，即其它事务既不能读，又不能改排他锁锁定的资源。
   例10
   T1:    update table set column1='hello' where id<1000
   T2:    update table set column1='world' where id>1000
   
   假设T1先达，T2随后至，这个过程中T1会对id<1000的记录施加排他锁.但不会阻塞T2的update。
   
   例11 (假设id都是自增长且连续的）
   T1:    update table set column1='hello' where id<1000
   T2:    update table set column1='world' where id>900
   
   如同例10，T1先达，T2立刻也到，T1加的排他锁会阻塞T2的update.

4. 意向锁(Intent Locks)

   意向锁就是说在屋（比如代表一个表）门口设置一个标识，说明屋子里有人（比如代表某些记录）被锁住了。另一个人想知道屋子
   里是否有人被锁，不用进屋子里一个一个的去查，直接看门口标识就行了。
   
   当一个表中的某一行被加上排他锁后，该表就不能再被加表锁。数据库程序如何知道该表不能被加表锁？一种方式是逐条的判断该
   表的每一条记录是否已经有排他锁，另一种方式是直接在表这一层级检查表本身是否有意向锁，不需要逐条判断。显然后者效率高。
   
   例12：
   ----------------------------------------
   T1:    begin tran
          select * from table (xlock) where id=10  --意思是对id=10这一行强加排他锁
   T2:    begin tran
          select * from table (tablock)     --意思是要加表级锁
          
   假设T1先执行，T2后执行，T2执行时，欲加表锁，为判断是否可以加表锁，数据库系统要逐条判断table表每行记录是否已有排他锁，
   如果发现其中一行已经有排他锁了，就不允许再加表锁了。只是这样逐条判断效率太低了。
   
   实际上，数据库系统不是这样工作的。当T1的select执行时，系统对表table的id=10的这一行加了排他锁，还同时悄悄的对整个表
   加了意向排他锁(IX)，当T2执行表锁时，只需要看到这个表已经有意向排他锁存在，就直接等待，而不需要逐条检查资源了。
   
   例13：
   ----------------------------------------
   T1:    begin tran
          update table set column1='hello' where id=1
   T2:    begin tran
          update table set column1='world' where id=1
   
   这个例子和上面的例子实际效果相同，T1执行，系统对table同时对行家排他锁、对页加意向排他锁、对表加意向排他锁。

5. 计划锁(Schema Locks)

   例14：
   ----------------------------------------
   alter table .... (加schema locks，称之为Schema modification (Sch-M) locks
   
   DDL语句都会加Sch-M锁
   该锁不允许任何其它session连接该表。连都连不了这个表了，当然更不用说想对该表执行什么sql语句了。
   
   例15:
   ----------------------------------------
   用jdbc向数据库发送了一条新的sql语句，数据库要先对之进行编译，在编译期间，也会加锁，称之为：Schema stability (Sch-S) locks
   
   select * from tableA
   
   编译这条语句过程中，其它session可以对表tableA做任何操作(update,delete，加排他锁等等），但不能做DDL(比如alter table)操作。

6. Bulk Update Locks 主要在批量导数据时用（比如用类似于oracle中的imp/exp的bcp命令）。不难理解，程序员往往也不需要关心，不赘述了。

如何加锁，何时加锁，加什么锁，你可以通过hint手工强行指定，但大多是数据库系统自动决定的。这就是为什么我们可以不懂锁也可
以高高兴兴的写SQL。

例15:
----------------------------------------
T1:    begin tran
       update table set column1='hello' where id=1
T2:    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED  -- 事物隔离级别为允许脏读
       go
       select * from table where id=1
这里，T2的select可以查出结果。如果事物隔离级别不设为脏读，则T2会等T1事物执行完才能读出结果。

数据库如何自动加锁的？

1) T1执行，数据库自动加排他锁
2) T2执行，数据库发现事物隔离级别允许脏读，便不加共享锁。不加共享锁，则不会与已有的排他锁冲突，所以可以脏读。

例16:
----------------------------------------
T1:    begin tran
       update table set column1='hello' where id=1
T2:    select * from table where id=1 --为指定隔离级别，则使用系统默认隔离级别，它不允许脏读

如果事物级别不设为脏读，则：
1) T1执行，数据库自动加排他锁
2) T2执行，数据库发现事物隔离级别不允许脏读，便准备为此次select过程加共享锁，但发现加不上，因为已经有排他锁了，所以就
   等啊等。直到T1执行完，释放了排他锁，T2才加上了共享锁，然后开始读....

锁的粒度就是指锁的生效范围，就是说是行锁，还是页锁，还是整表锁. 锁的粒度同样既可以由数据库自动管理，也可以通过手工指定hint来管理。

例17：
----------------------------------------
T1:    select * from table (paglock)
T2:    update table set column1='hello' where id>10

T1执行时，会先对第一页加锁，读完第一页后，释放锁，再对第二页加锁，依此类推。假设前10行记录恰好是一页(当然，一般不可能
一页只有10行记录），那么T1执行到第一页查询时，并不会阻塞T2的更新。

例18：
----------------------------------------
T1:    select * from table (rowlock)
T2:    update table set column1='hello' where id=10

T1执行时，对每行加共享锁，读取，然后释放，再对下一行加锁;T2执行时，会对id=10的那一行试图加锁，只要该行没有被T1加上行锁，
T2就可以顺利执行update操作。

例19：
----------------------------------------
T1:    select * from table (tablock)
T2:    update table set column1='hello' where id = 10

T1执行，对整个表加共享锁. T1必须完全查询完，T2才可以允许加锁，并开始更新。

以上3例是手工指定锁的粒度，也可以通过设定事物隔离级别，让数据库自动设置锁的粒度。不同的事物隔离级别，数据库会有不同的
加锁策略（比如加什么类型的锁，加什么粒度的锁）。具体请查联机手册。

手工指定的锁优先，
例20:
----------------------------------------
T1:    GO
       SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
       GO
       BEGIN TRANSACTION
       SELECT * FROM table (NOLOCK)
       GO
T2:    update table set column1='hello' where id=10

T1是事物隔离级别为最高级，串行锁，数据库系统本应对后面的select语句自动加表级锁，但因为手工指定了NOLOCK，所以该select
语句不会加任何锁，所以T2也就不会有任何阻塞。

1) holdlock 对表加共享锁，且事物不完成，共享锁不释放。
2) tablock  对表加共享锁，只要statement不完成，共享锁不释放。
   与holdlock区别，见下例：
   例21
   ----------------------------------------
   T1:
   begin tran
   select * from table (tablock)
   T2:
   begin tran
   update table set column1='hello' where id = 10

   T1执行完select，就会释放共享锁，然后T2就可以执行update. 此之谓tablock. 下面我们看holdlock
   例22
   ----------------------------------------
   T1:
   begin tran
   select * from table (holdlock)
   T2:
   begin tran
   update table set column1='hello' where id = 10
   
   T1执行完select，共享锁仍然不会释放，仍然会被hold(持有），T2也因此必须等待而不能update. 当T1最后执行了commit或
   rollback说明这一个事物结束了，T2才取得执行权。
  
3) TABLOCKX 对表加排他锁
  
   例23：
   ----------------------------------------
   T1:    select * from table(tablockx) (强行加排他锁）
   其它session就无法对这个表进行读和更新了，除非T1执行完了，就会自动释放排他锁。
   例24：
   ----------------------------------------
   T1:    begin tran
          select * from table(tablockx)
   这次，单单select执行完还不行，必须整个事物完成（执行了commit或rollback后）才会释放排他锁。
  
4) xlock 加排他锁
   那它跟tablockx有何区别呢？

   它可以这样用，
   例25:
   ----------------------------------------
   select * from table(xlock paglock) 对page加排他锁
   而TABLELOCX不能这么用。

   xlock还可这么用：select * from table(xlock tablock) 效果等同于select * from table(tablockx)

例26

SET LOCK_TIMEOUT 4000 用来设置锁等待时间，单位是毫秒，4000意味着等待
4秒可以用select @@LOCK_TIMEOUT查看当前session的锁超时设置。-1 意味着
永远等待。

T1: begin tran
    udpate table set column1='hello' where id = 10
T2: set lock_timeout 4000
    select * from table wehre id = 10

T2执行时，会等待T1释放排他锁，等了4秒钟，如果T1还没有释放排他锁，T2就会抛出异常： Lock request time out period exceeded.

| Requested mode                     | IS  | S   | U   | IX  | SIX | X  |
| Intent shared (IS)                 | Yes | Yes | Yes | Yes | Yes | No |
| Shared (S)                         | Yes | Yes | Yes | No  | No  | No |
| Update (U)                         | Yes | Yes | No  | No  | No  | No |
| Intent exclusive (IX)              | Yes | No  | No  | Yes | No  | No |
| Shared with intent exclusive (SIX) | Yes | No  | No  | No  | No  | No |
| Exclusive (X)                      | No  | No  | No  | No  | No  | No |

1. 悲观锁：利用数据库本身的锁机制实现。通过上面对数据库锁的了解，可以根据具体业务情况综合使用事务隔离级别与合理的手工指定锁的方式比如降低锁的粒度等减少并发等待。
2. 乐观锁：利用程序处理并发。原理都比较好理解，基本一看即懂。方式大概有以下3种
   1. 对记录加版本号.
   2. 对记录加时间戳.
   3. 对将要更新的数据进行提前读取、事后对比。

不论是数据库系统本身的锁机制，还是乐观锁这种业务数据级别上的锁机制，本质上都是对状态位的读、写、判断。

多个进程或线程同时(或着说在同一段时间内)访问同一资源会产生并发问题。

银行两操作员同时操作同一账户就是典型的例子。比如A、B操作员同时读取一余额为1000元的账户，A操作员为该账户增加100元，B操作员同时为该账户减去 50元，A先提交，B后提交。 最后实际账户余额为1000-50=950元，但本该为 1000+100-50=1050。这就是典型的并发问题。如何解决？可以用锁。

1. 用法1

   public class Test{
       public synchronized void print(){
           ....;
       } 
   }
   

   某线程执行print()方法，则该对象将加锁。其它线程将无法执行该对象的所有synchronized块。

2. 用法2

   public class Test{
       public void print(){
           synchronized(this){//锁住本对象
               ...;
           }
       }
   }
   

   同用法1, 但更能体现synchronized用法的本质。

3. 用法3

   public class Test{
       private String a = "test";
       public void print(){
           synchronized(a){//锁住a对象
               ...;
           }
       }
       public synchronized void t(){
           ...; //这个同步代码块不会因为print()而锁定.
       }
   }
   

   执行print()，会给对象a加锁，注意不是给Test的对象加锁，也就是说 Test对象的其它synchronized方法不会因为print()而被锁。同步代码块执行完，则释放对a的锁。

   为了锁住一个对象的代码块而不影响该对象其它 synchronized块的高性能写法：

   public class Test{
       private byte[] lock = new byte[0];
       public void print(){
           synchronized(lock){
               ...;
           }
       }
       public synchronized void t(){
           ...; 
       }
   }
   

4. 静态方法的锁

   public class Test{
       public synchronized static void execute(){
           ...;
       }
   }
   

   效果同

   public class Test{
       public static void execute(){
           synchronized(TestThread.class){
               ...;
           }
       }
   }
   

锁就是阻止其它进程或线程进行资源访问的一种方式，即锁住的资源不能被其它请求访问。在JAVA中，sychronized关键字用来对一个对象加锁。比如:

public class MyStack {
    int idx = 0;
    char [] data = new char[6];

    public synchronized void push(char c) {
        data[idx] = c;
        idx++;
    }

    public synchronized char pop() {
        idx--;
        return data[idx];
    }

    public static void main(String args[]){
        MyStack m = new MyStack();
        /**
           下面对象m被加锁。严格的说是对象m的所有synchronized块被加锁。
           如果存在另一个试图访问m的线程T，那么T无法执行m对象的push和
           pop方法。
        */
        m.pop();//对象m被加锁。
    }
}

Java的加锁解锁跟多个人排队等一个公共厕位完全一样。第一个人进去后顺手把门从里面锁住，其它人只好排队等。第一个人结束后出来时，门才会打开（解锁）。轮到第二个人进去，同样他又会把门从里面锁住，其它人继续排队等待。

用厕所理论可以很容易明白: 一个人进了一个厕位，这个厕位就会锁住，但不会导致另一个厕位也被锁住，因为一个人不能同时蹲在两个厕位里。对于Java 就是说：Java中的锁是针对同一个对象的，不是针对class的。看下例：

MyStatck m1 = new MyStack();
MyStatck m2 = new Mystatck();
m1.pop();
m2.pop();  

m1对象的锁是不会影响m2的锁的，因为它们不是同一个厕位。就是说，假设有 3线程t1,t2,t3操作m1，那么这3个线程只可能在m1上排队等，假设另2个线程 t8,t9在操作m2，那么t8,t9只会在m2上等待。而t2和t8则没有关系，即使m2上的锁释放了，t1,t2,t3可能仍要在m1上排队。原因无它，不是同一个厕位耳。

Java不能同时对一个代码块加两个锁，这和数据库锁机制不同，数据库可以对一条记录同时加好几种不同的锁，请参见：

http://hi.baidu.com/dapplehou/blog/item/b341a97744fe6616b151b9a3.html

一般是执行完毕同步代码块（锁住的代码块）后就释放锁，也可以用wait()方式半路上释放锁。wait()方式就好比蹲厕所到一半，突然发现下水道堵住了，不得已必须出来站在一边，好让修下水道师傅(准备执行notify的一个线程）进去疏通马桶，疏通完毕，师傅大喊一声: "已经修好了"(notify)，刚才出来的同志听到后就重新排队。注意啊，必须等师傅出来啊，师傅不出来，谁也进不去。也就是说notify后，不是其它线程马上可以进入封锁区域活动了，而是必须还要等notify代码所在的封锁区域执行完毕从而释放锁以后，其它线程才可进入。

这里是wait与notify代码示例：

public synchronized char pop() {
    char c;
    while (buffer.size() == 0) {
        try {
            this.wait(); //从厕位里出来
        } catch (InterruptedException e) {
            // ignore it...
        }
    }
    c = ((Character)buffer.remove(buffer.size()-1)).
        charValue();
    return c;
}

public synchronized void push(char c) {
    this.notify(); //通知那些wait()的线程重新排队。注意：仅仅是通知它们重新排队。
    Character charObj = new Character(c);
    buffer.addElement(charObj);
}//执行完毕，释放锁。那些排队的线程就可以进来了。

再深入一些。

由于wait()操作而半路出来的同志没收到notify信号前是不会再排队的，他会在旁边看着这些排队的人(其中修水管师傅也在其中）。注意，修水管的师傅不能插队，也得跟那些上厕所的人一样排队，不是说一个人蹲了一半出来后，修水管师傅就可以突然冒出来然后立刻进去抢修了，他要和原来排队的那帮人公平竞争，因为他也是个普通线程。如果修水管师傅排在后面，则前面的人进去后，发现堵了，就wait，然后出来站到一边，再进去一个，再wait，出来，站到一边，只到师傅进去执行notify. 这样，一会儿功夫，排队的旁边就站了一堆人，等着notify.

终于，师傅进去，然后notify了，接下来呢？

1. 有一个wait的人（线程）被通知到。
2. 为什么被通知到的是他而不是另外一个wait的人？取决于JVM.我们无法预先
   判断出哪一个会被通知到。也就是说，优先级高的不一定被优先唤醒，等待
   时间长的也不一定被优先唤醒，一切不可预知！(当然，如果你了解该JVM的
   实现，则可以预知）。
3. 他（被通知到的线程）要重新排队。
4. 他会排在队伍的第一个位置吗？回答是：不一定。他会排最后吗？也不一定。
   但如果该线程优先级设的比较高，那么他排在前面的概率就比较大。
5. 轮到他重新进入厕位时，他会从上次wait()的地方接着执行，不会重新执行。
   恶心点说就是，他会接着拉巴巴，不会重新拉。
6. 如果师傅notifyAll(). 则那一堆半途而废出来的人全部重新排队。顺序不可知。

Java DOC 上说，The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object(当前线程释放锁前，唤醒的线程不能去执行）。

这用厕位理论解释就是显而易见的事。

用synchronized关键字可以对资源加锁。用Lock关键字也可以。它是JDK1.5中新增内容。用法如下：

class BoundedBuffer {
    final Lock lock = new ReentrantLock();
    final Condition notFull  = lock.newCondition(); 
    final Condition notEmpty = lock.newCondition(); 

    final Object[] items = new Object[100];
    int putptr, takeptr, count;

    public void put(Object x) throws InterruptedException {
        lock.lock();
        try {
            while (count == items.length) 
                notFull.await();
            items[putptr] = x; 
            if (++putptr == items.length) putptr = 0;
            ++count;
            notEmpty.signal();
        } finally {
            lock.unlock();
        }
    }

    public Object take() throws InterruptedException {
        lock.lock();
        try {
            while (count == 0) 
                notEmpty.await();
            Object x = items[takeptr]; 
            if (++takeptr == items.length) takeptr = 0;
            --count;
            notFull.signal();
            return x;
        } finally {
            lock.unlock();
        }
    } 
}

(注：这是JavaDoc里的例子，是一个阻塞队列的实现例子。所谓阻塞队列，就是一个队列如果满了或者空了，都会导致线程阻塞等待。Java里的 ArrayBlockingQueue提供了现成的阻塞队列，不需要自己专门再写一个了。)

一个对象的lock.lock()和lock.unlock()之间的代码将会被锁住。这种方式比起synchronize好在什么地方？简而言之，就是对wait的线程进行了分类。用厕位理论来描述，则是那些蹲了一半而从厕位里出来等待的人原因可能不一样，有的是因为马桶堵了，有的是因为马桶没水了。通知(notify)的时候，就可以喊：因为马桶堵了而等待的过来重新排队（比如马桶堵塞问题被解决了），或者喊，因为马桶没水而等待的过来重新排队(比如马桶没水问题被解决了）。这样可以控制得更精细一些。不像synchronize里的wait和notify，不管是马桶堵塞还是马桶没水都只能喊：刚才等待的过来排队！假如排队的人进来一看，发现原来只是马桶堵塞问题解决了，而自己渴望解决的问题（马桶没水）还没解决，只好再回去等待(wait)，白进来转一圈，浪费时间与资源。

Lock方式与synchronized对应关系：

注意：不要在Lock方式锁住的块里调用wait、notify、notifyAll

原理简单。两个线程，一个操作PipedInputStream,一个操作 PipedOutputStream。PipedOutputStream写入的数据先缓存在Buffer中,如果 Buffer满，此线程wait。PipedInputStream读出Buffer中的数据，如果Buffer 没数据，此线程wait。

jdk1.5中的阻塞队列可实现同样功能。

1. 例1 这个例子实际上只是单线程，还谈不上线程间通信，但不妨一看。

   http://hi.baidu.com/ecspell/blog/item/7b02d3133ab555005aaf53f5.html

   package io;
   import java.io.*;
   public class PipedStreamTest {
       public static void main(String[] args) {
           PipedOutputStream ps=new PipedOutputStream();
           PipedInputStream pis=new PipedInputStream();
           try{
               ops.connect(pis);//实现管道连接
               new Producer(ops).run();
               new Consumer(pis).run();
           }catch(Exception e){
               e.printStackTrace();
           }
   
       }
   }
   
   //生产者
   class Producer implements Runnable{
       private PipedOutputStream ops;
       public Producer(PipedOutputStream ops)
       {
           this.ops=ops;
       }
   
       public void run()
       {
           try{
               ops.write("hell,spell".getBytes());
               ops.close();
           }catch(Exception e)
               {e.printStackTrace();}
       }
   }
   
   //消费者
   class Consumer implements Runnable{
       private PipedInputStream pis;
       public Consumer(PipedInputStream pis)
       {
           this.pis=pis;
       }
   
       public void run()
       {
           try{
               byte[] bu=new byte[100];
               int len=pis.read(bu);
               System.out.println(new String(bu,0,len));
               pis.close();
           }catch(Exception e)
               {e.printStackTrace();}
       }
   } 
   

2. 例2 对上面的程序做少许改动就成了两个线程。

   package io;
   import java.io.*;
   public class PipedStreamTest {
       public static void main(String[] args) {
           PipedOutputStream ps=new PipedOutputStream();
           PipedInputStream pis=new PipedInputStream();
           try{
               ops.connect(pis);//实现管道连接
               Producer p = new Producer(ops);
               new Thread(p).start();
               Consumer c = new Consumer(pis);
               new Thread(c).start();
           }catch(Exception e){
               e.printStackTrace();
           }
   
       }
   }
   
   //生产者
   class Producer implements Runnable{
       private PipedOutputStream ops;
       public Producer(PipedOutputStream ops)
       {
           this.ops=ops;
       }
   
       public void run()
       {
           try{
               for(;;){
                   ops.write("hell,spell".getBytes());
                   ops.close();
               }
           }catch(Exception e)
               {e.printStackTrace();}
       }
   }
   
   //消费者
   class Consumer implements Runnable{
       private PipedInputStream pis;
       public Consumer(PipedInputStream pis)
       {
           this.pis=pis;
       }
   
       public void run()
       {
           try{
               for(;;){
                   byte[] bu=new byte[100];
                   int len=pis.read(bu);
                   System.out.println(new String(bu,0,len));
               }
               pis.close();
           }catch(Exception e)
               {e.printStackTrace();}
       }
   }
   

3. 例3. 这个例子更加贴进应用

   import java.io.*;
          
   public class PipedIO { //程序运行后将sendFile文件的内容拷贝到receiverFile文件中
       public static void main(String args[]){       
           try{//构造读写的管道流对象       
               PipedInputStream pis=new PipedInputStream();       
               PipedOutputStream pos=new PipedOutputStream();       
               //实现关联       
               pos.connect(pis);       
               //构造两个线程，并且启动。           
               new Sender(pos,"c:\\text2.txt").start();           
               new Receiver(pis,"c:\\text3.txt").start();         
           }catch(IOException e){       
               System.out.println("Pipe Error"+ e);       
           }       
       }       
   }       
   //线程发送       
   class Sender extends Thread{           
       PipedOutputStream pos;       
       File file;       
       //构造方法       
       Sender(PipedOutputStream pos, String fileName){       
           this.pos=pos;       
           file=new File(fileName);       
       }          
       //线程运行方法       
       public void run(){          
           try{       
               //读文件内容       
               FileInputStream fs=new FileInputStream(file);       
               int data;       
               while((data=fs.read())!=-1){       
                   //写入管道始端       
                   pos.write(data);       
               }       
               pos.close();                        
           }       
           catch(IOException e) {       
               System.out.println("Sender Error" +e);       
           }       
       }       
   }
          
   //线程读       
   class Receiver extends Thread{       
       PipedInputStream pis;       
       File file;       
       //构造方法       
       Receiver(PipedInputStream pis, String fileName){         
           this.pis=pis;       
           file=new File(fileName);       
       }          
       //线程运行       
       public void run(){          
           try {       
               //写文件流对象       
               FileOutputStream fs=new FileOutputStream(file);       
               int data;       
               //从管道末端读       
               while((data=pis.read())!=-1){
          
                   //写入本地文件       
                   fs.write(data);       
               }       
               pis.close();            
           }       
           catch(IOException e){       
               System.out.println("Receiver Error" +e);       
           }       
       }       
   }
   

阻塞队列可以代替管道流方式来实现进水管/排水管模式（生产者/消费者).JDK1.5提供了几个现成的阻塞队列. 现在来看ArrayBlockingQueue的代码如下：

这里是一个阻塞队列

BlockingQueue<Object> blockingQ = new ArrayBlockingQueue<Object> 10;

一个线程从队列里取

for(;;){
    Object o = blockingQ.take();//队列为空，则等待（阻塞）
}

另一个线程往队列存

for(;;){
    blockingQ.put(new Object());//队列满，则等待（阻塞）
}

可见，阻塞队列使用起来比管道简单。

可以使用线程管理任务。还可以使用jdk1.5提供的一组类来更方便的管理任务。从这些类里我们可以体会一种面向任务的思维方式。这些类是：

1. Executor接口。使用方法：

   Executor executor = anExecutor;//生成一个Executor实例。
   executor.execute(new RunnableTask1());
   

   用意：使用者只关注任务执行，不用操心去关注任务的创建、以及执行细节等这些第三方实现者关心的问题。也就是说，把任务的调用执行和任务的实现解耦。

   实际上，JDK1.5中已经有该接口出色的实现。够用了。

2. Executors是一个如同Collections一样的工厂类或工具类，用来产生各种不同接口的实例。
3. ExecutorService接口它继承自Executor. Executor只管把任务扔进 executor()里去执行，剩余的事就不管了。而ExecutorService则不同，它会多做点控制工作。比如：

   class NetworkService {
       private final ServerSocket serverSocket;
       private final ExecutorService pool;
   
       public NetworkService(int port, int poolSize) throws IOException {
           serverSocket = new ServerSocket(port);
           pool = Executors.newFixedThreadPool(poolSize);
       }
    
       public void serve() {
           try {
               for (;;) {
                   pool.execute(new Handler(serverSocket.accept()));
               }
           } catch (IOException ex) {
               pool.shutdown(); //不再执行新任务
           }
       }
   }
   
   class Handler implements Runnable {
       private final Socket socket;
       Handler(Socket socket) { this.socket = socket; }
       public void run() {
           // read and service request
       }
   }
   

   ExecutorService(也就是代码里的pool对象）执行shutdown后，它就不能再执行新任务了，但老任务会继续执行完毕，那些等待执行的任务也不再等待了。

4. 任务提交者与执行者通讯

   public static void main(String args[])throws Exception {
       ExecutorService executor = Executors.newSingleThreadExecutor();
       Callable<String> task = new Callable<String>(){
           public String call()throws Exception{
               return "test";
           }
       };
       Future<String> f = executor.submit(task); 
       String result = f.get();//等待（阻塞）返回结果
       System.out.println(result);
       executor.shutdown();                
   }
   

   Executors.newSingleThreadExecutor()取得的Executor实例有以下特性:

   1. 任务顺序执行. 比如：

      executor.submit(task1);
      executor.submit(task2);
      

      必须等task1执行完，task2才能执行。

   2. task1和task2会被放入一个队列里，由一个工作线程来处理。即：一共有2个线程(主线程、处理任务的工作线程）。
5. 其它的类请参考Java Doc

本节例子来自温少的Java并发教程，可能会有改动。向温少致敬。

1. CountDownLatch 门插销计数器
   1. 启动线程，然后等待线程结束。即常用的主线程等所有子线程结束后再执行的问题。

      public static void main(String[] args)throws Exception {
          // TODO Auto-generated method stub
          final int count=10;
          final CountDownLatch completeLatch = new CountDownLatch(count);//定义了门插销的数目是10
                      
          for(int i=0;i<count;i++){
              Thread thread = new Thread("worker thread"+i){
                      public void run(){
                          //do xxxx                                   
                          completeLatch.countDown();//减少一根门插销
                      }
                  };
              thread.start();
          }           
          completeLatch.await();//如果门插销还没减完则等待。
      } 
      

      JDK1.4时，常用办法是给子线程设置状态，主线程循环检测。易用性和效率都不好。

   2. 启动很多线程，等待通知才能开始

      public static void main(String[] args) throws Exception {
          // TODO Auto-generated method stub
          final CountDownLatch startLatch = new CountDownLatch(1);//定义了一根门插销
      
          for (int i = 0; i < 10; i++) {
              Thread thread = new Thread("worker thread" + i) {
                      public void run() {
                          try {
                              startLatch.await();//如果门插销还没减完则等待
                          } catch (InterruptedException e) {
      
                          }
                          // do xxxx
                      }
                  };
              thread.start();
          }
          startLatch.countDown();//减少一根门插销
      }
      

2. CycliBarrier. 等所有线程都达到一个起跑线后才能开始继续运行。

   public class CycliBarrierTest implements Runnable {
       private CyclicBarrier barrier;
   
       public CycliBarrierTest(CyclicBarrier barrier) {
           this.barrier = barrier;
       }
   
       public void run() {
           //do xxxx;
           try {
               this.barrier.await();//线程运行至此会检查是否其它线程都到齐了，没到齐就继续等待。到齐了就执行barrier的run函数体里的内容
           } catch (Exception e) {
   
           }
       }
   
       /**
        * @param args
        */
       public static void main(String[] args) {
           //参数2代表两个线程都达到起跑线才开始一起继续往下执行
           CyclicBarrier barrier = new CyclicBarrier(2, new Runnable() {
                   public void run() {
                       //do xxxx;
                   }
               });
           Thread t1 = new Thread(new CycliBarrierTest(barrier));         
           Thread t2 = new Thread(new CycliBarrierTest(barrier));
           t1.start();
           t2.start();
       }
   
   }
   

   这简化了传统的用计数器+wait/notifyAll来实现该功能的方式。

1. Amdahl定律. 给定问题规模，可并行化部分占12%，那么即使把并行运用到极致，系统的性能最多也只能提高1/(1-0.12)=1.136倍。即：并行对提高系统性能有上限。
2. Gustafson定律. Gustafson定律说Amdahl定律没有考虑随着cpu的增多而有更多的计算能力可被使用。其本质在于更改问题规模从而可以把Amdahl定律中那剩下的88%的串行处理并行化，从而可以突破性能门槛。本质上是一种空间换时间。
3. Sun-Ni定律. 是前两个定律的进一步推广。其主要思想是计算的速度受限于存储而不是CPU的速度. 所以要充分利用存储空间等计算资源，尽量增大问题规模以产生更好/更精确的解.

计算机识别物体需要飞速的计算，以至于芯片发热发烫，而人在识别物体时却一目了然，却并不会导致某个脑细胞被烧热烧焦（夸张）而感到不适，是由于大脑是一个分布式并行运行系统，就像google用一些廉价的linux服务器可以进行庞大复杂的计算一样，大脑内部无数的神经元的独自计算，互相分享成果，从而瞬间完成需要单个cpu万亿次运算才能有的效果。试想，如果在并行处理领域有所创建，将对计算机的发展和未来产生不可估量的影响。当然，其中的挑战也可想而知：许多的问题是并不容易轻易就“分割”的了的。