java锁机制Synchronized
原文引自http://hi.baidu.com/heyinjie/blog/item/608ee7108f1f4802203f2e35.html
打个比方：一个object就像一个大房子，大门永远打开。房子里有很多房间（也就是方法）。这些房间有上锁的（synchronized方法）， 和不上锁之分（普通方法）。房门口放着一把钥匙（key），这把钥匙可以打开所有上锁的房间。另外我把所有想调用该对象方法的线程比喻成想进入这房子某个 房间的人。所有的东西就这么多了，下面我们看看这些东西之间如何作用的。
在此我们先来明确一下我们的前提条件。该对象至少有一个synchronized方法，否则这个key还有啥意义。当然也就不会有我们的这个主题了。
一个人想进入某间上了锁的房间，他来到房子门口，看见钥匙在那儿（说明暂时还没有其他人要使用上锁的房间）。于是他走上去拿到了钥匙，并且按照自己 的计划使用那些房间。注意一点，他每次使用完一次上锁的房间后会马上把钥匙还回去。即使他要连续使用两间上锁的房间，中间他也要把钥匙还回去，再取回来。
因此，普通情况下钥匙的使用原则是：“随用随借，用完即还。”
这时其他人可以不受限制的使用那些不上锁的房间，一个人用一间可以，两个人用一间也可以，没限制。但是如果当某个人想要进入上锁的房间，他就要跑到大门口去看看了。有钥匙当然拿了就走，没有的话，就只能等了。
要是很多人在等这把钥匙，等钥匙还回来以后，谁会优先得到钥匙？Not guaranteed。象前面例子里那个想连续使用两个上锁房间的家伙，他中间还钥匙的时候如果还有其他人在等钥匙，那么没有任何保证这家伙能再次拿到。 （JAVA规范在很多地方都明确说明不保证，象Thread.sleep()休息后多久会返回运行，相同优先权的线程那个首先被执行，当要访问对象的锁被 释放后处于等待池的多个线程哪个会优先得到，等等。我想最终的决定权是在JVM，之所以不保证，就是因为JVM在做出上述决定的时候，绝不是简简单单根据 一个条件来做出判断，而是根据很多条。而由于判断条件太多，如果说出来可能会影响JAVA的推广，也可能是因为知识产权保护的原因吧。SUN给了个不保证 就混过去了。无可厚非。但我相信这些不确定，并非完全不确定。因为计算机这东西本身就是按指令运行的。即使看起来很随机的现象，其实都是有规律可寻。学过 计算机的都知道，计算机里随机数的学名是伪随机数，是人运用一定的方法写出来的，看上去随机罢了。另外，或许是因为要想弄的确定太费事，也没多大意义，所 以不确定就不确
相关文档：
使用一种程序设计语言，就应该专业地使用它。本文是IBM developerWorks中的一篇文章，它描述的都是Java编程中的细节问题，尽管如此，还是值得大家玩味一番，至少我作为一名老鸟还是从中受益了。(2010.02.09最后更新)
学习一种新的程序设计语言比学习一种新的口头语言要容易。但是，在这两种努力中，都� ......
public int ExecProcAdd()
{
SqlCommand cmd = new SqlCommand();
cmd.CommandType = CommandType.StoredProcedu ......
import java.io.InputStream;
import org.apache.lucene.document.Document;
import org.apache.poi.hslf.HSLFSlideShow;
import org.apache.poi.hslf.model.TextRun;
import org.apache.poi.hslf.model.Slide;
import org.apache.poi.hslf.usermodel.SlideShow;
public Document getDocument(Index index, String ur ......
场景：现在有个磁盘输出的业务，客户端需要通过2个业务对象进行输出。
一个是通过Floppy(软盘)，另一个是通过USB接口。
这样就需要2个业务类，但是如果不让客户端知道而实现简单的注入呢？
首先，由于有2种设备，软盘和USB，因此我们需要建立一个设备接口IDeviceWriter。
代码如下： ......
