线程笔记,尽供参考[转贴]

贴一下我以前看线程的时候的部分笔记：

在java中，每个对象只有一个相应的monitor，一个mutex，而每一个monitor都可以有多个“doors”可以进入，即，同一个monitor中被守护的代码可以在不同的地方，因为同一个对象可以出现在不同的代码段，只要mutex锁定的对象是同一个，每个入口都用Synchronized关键字表明，当一个线程通过了Synchronized关键字，它就所住了该monitor所有的doors。因此是mutex定义了monitor而不是代码。

为了方便理解monitor的概念举个例子：
飞机山只有一个洗手间，很多乘客都想进去，但一次只能进去一个人，其他人必须等待，此时有如下对应关系：

飞机：object
乘客：各个线程
洗手间：monitor
洗手间门上的锁：mutex

因为同步的花销很大，因此要尽量避免：
1，不需要同步原子操作：一个原子操作不会被另一个线程中断，所以原子操作不需要被同步；
2，避免同步，在语言上意味着“不变性”，一个具有不变性的对象的状态在其创建之后就不会改变，因此不变的对象不需要同步；通常频繁的访问一个对象，而不修改它，那么该对象就不需要同步，好的方法是使该对象为不可变的；
3，使用同步包装器，用装饰模式可以在同步与不同步之间选择。

另，java规范中并没有要求wait()方法要作为原子操作实现的，因此，判断是否wait()的条件用while比if要好，因为if虽然在某些java实现中起作用，但是其行为实际是不明确的，用while条件也称spin lock，用其代替if只是为了保险起见。（关于这一点while和if偶理解的不是太明白）

 

要理解同步的本质，就要明白操作系统是如何执行程序的。对于进程和线程，操作系统设计者的目的是从概念上简化编程模型，使编程显得更自然，更符合思维习惯。操作系统设计者为使用进程和线程来编程提供了一个假设条件，即进程和线程各自的执行流是连贯的，没有任何断续执行的现象。但是实际上（以单CPU系统为例），从系统实现的底层看起来，这些进程和线程的执行流是支离破碎的，并且这些破碎的执行流片断被CPU以某种方式（即操作系统的调度程序）组合成一个串行的、混合在一起的执行流，以此推动操作系统不断运行。问题就在这里，同步问题的根源就在于看起来连贯的执行流实际上是破碎的。破碎的执行流会造成什么问题呢？比如有两个执行流A和B，A对现在需要对一个数据进行操作，但是这个操作被分割成了相连的两块执行流碎片，而另外一个执行流B本来需要在A完成这个数据操作之后才能取到这个数据然后进行它自己的计算，可是由于A对数据本应完整的操作被分割成了相连的两部分，然后CPU在A的碎片之间插入了B的取数这样一个执行流片断。这样一来，程序的行为就不符合我们原本所设想的那样，程序运行的结果就会出错。同步的本质就是让CPU不要把A的数据操作分割开，不让B有机会错误的横插一杠进来扰乱A，以保证正确的执行顺序，这样才能得到正确的我们想要的结果。不管你看起来执行得多么快的操作，都有可能被操作系统打断，从而形成碎片，导致无法预料的结果。所以，应该在需要精确时序的地方使用同步，而不是根据这个操作快不快来判断。所谓需要精确时序场合，其实就是数据的使用或操作的执行存在依赖性的地方，对于代码来说，就是完成某项操作时对参与的进程或线程执行顺序存在依赖性的代码块。

 

线程是一个基本问题, 有它的问题域, java中显示的实现了一部分, 隐式
的实现了一部分.
就像上文提到的mointer, mutex, 在术语上还有race condition, value condition,semaphore等
java中的Synchronized就是race condition问题,即占先问题, 其中自然
就会有mointer,mutex的概念.
wait(), notify() notifyAll()等实现了 value condition, 即去等待一个条件.
而java中要求wait(), nofity()等必须在一个Synchronized体中也是有它的
隐含意义的.
想向大家推荐一本书 thread primer, 书中虽然讲的主要是PThread, 但基本概念是介绍的相当清楚的, 能够给我们提供一个系统的且扎实的概念体系. 不知这里是否有提供上载的地方, 我可以提供. epubcn上应该也可以找到.
to mochow: 你所说的while(), if()问题, 是一个比较关键的问题.
也就是说, 从代码上看, wait()要写在while(xxx)中,而不是if(xxx)中.
"java规范中并没有要求wait()方法要作为原子操作实现的"这句话我觉得
不够明确,因为所谓的原子操作是通过获得能否获得mutex实现的, 而wait()
自然是要释放mutex的, 否则启不是只能有一个等待吗?
当有多个线程wait时,如果在另一个线程中notifyAll(),那些等待的线程就会重新去争夺mutex,这是你就会发现,如果wait是在while中的话,它在获得
mutex后还会去判断一次条件, 所以说第一个获得mutex的线程在这里应该
是通过的, 而其他的线程就会被再次wait[如果你的程序写对的话], 而如果
是在if中的话,就没有这一步.
应该说在某些场景下, 是可以写if的.[这要看你的实际需要],我们所要
讨论的是: 要知道while和if的区别在那里.
你可以想象一个生产消费问题.
一个线程生产, 多个线程消费.
消费的线程应该会有这么一段
try{
if(haveNewOne) {wait();}
}catch..
haveNewOne = false;
return 东西;
那我们想象一下如果有多个消费线程在等待,这时有一个生产线程生产
出一个东西并nodifyAll(), 则那些消费的线程就会依次从挂起状态变为运行,
然后都返回那个东西. 如果这是你希望的, 那就没有问题. 可我想大多数的
生产消费问题应该是这样的: 即生产一个消费一个, 一个东西不能被消费多次. 所以这么看来就不对了. 那我们改为while呢, 哇! 那就没有问题了.
除第一个有幸夺得mutex外得线程还要再次等待,而这才是我们所需要得.