并发，其实是多线程才有的场景。。。

java 多线程？ 锁？ 现在看来，即使已经工作了4、5年，这仍然不是一个简单的问题。

其实java 本身有提供锁的机制。 比如 Object对象的 wait 、notify 方法。synchronized 的原理不过是直接调用对应的对象的 wait方法罢了！

看tomcat 源码的时候，多线程的地方就是直接用到了 wait 、notify等方法 —— 这些方法真高级， 一般哪里会用得着？？？！！！

1 synchronized

其实这个算是容易学的东西了，相对于java concurrent 包下面的类而言：

1 当一个线程进入一个对象的一个synchronized方法后，其它线程是否可进入此对象的其它方法?  如果其他方法是synchronized则答案是No，否则yes

2 代码块呢， synchronized(Object) {}  ？当一个线程进入一个synchronized包围的代码块后， 是否可进入此代码块?  No， 但是，当前代码块所在的对象没有被锁，仍然可以被访问（调用方法、其他代码块。。）。

同时，1、2可以是静态方法、代码块

问题1：

synchronized 加在静态方法（或代码块）前面， 对其他非静态的synchronized 方法是否有影响？  

答案是No， 因为synchronized 加在静态方法时，锁定是类的class原型，synchronized 加在非静态方法时，锁定的是类的具体对象， —— 两者是不同对象！

 类的class原型?? —— 这样说有些拗口，总之是不同对象！！！。 

问题2：

synchronized 方法/代码块 里面嵌套synchronized， 会怎么样？ 

我的答案是： 得先处理好外层synchronized了再说！ 难道不是很明显吗??… 

2 Object对象的 wait 、notify 等方法

synchronized和Lock的区别？

http://blog.csdn.net/hintcnuie/article/details/11022049

Lock 和 synchronized 有一点明显的区别 —— lock 必须在 finally 块中释放。否则，如果受保护的代码将抛出异常，锁就有可能永远得不到释放！这一点区别看起来可能没什么，但是实际上，它极为重要。

—–

synchronized 同步的代码块可以由JVM自动释放；Lock 需要程序员在finally块中手工释放

3 java concurrent api

ReentrantReadWriteLock存在的意义： http://blog.csdn.net/doudou_bb_08/article/details/2400941

———— 一般来说,进行共享互斥会使程序性能变差,但将写入的共享互斥与读取的共享互斥分开思考,就可以提升程序的性能.  简单说是提高了read时候的性能，如果是write，则还是一样。

vilatile 这神马啊， 太难搞了。。xx

http://blog.csdn.net/fancyerII/article/details/6783224 又是一篇经典好长文。

java Condition。   http://www.cnblogs.com/pingyuyue/archive/2012/03/16/2400816.html 看得xx了