java 锁2

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

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的区别？

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

-----

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

3 java concurrent api

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