并发，其实是多线程才有的场景。。。
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了
