一、使用Synchronized有哪些注意点：
1，锁对象不能为空
这是因为我们的锁对象的header word中要存储很多信息，比如锁的信息，如果连对象都没有，就没有对象头，这个锁是不能工作的。所以锁对象不能为空。
2，作用域不宜过大
降低出并发问题的可能性，但是没有达到我们多线程编程的目的，我们多线程编程就是为了提供程序的效率，在不需要串行的情况下我们并行地去工作，可以提高我们的效率，
3，避免死锁
如果synchronized嵌套，用的是不同的锁，就容易发生死锁。
二、如何选择Lock和Synchronized关键字？
1，尽可能使用java.util.concurrent的各种类，比如Atomic类或者是CountDownLatch这些类，使用这些类的时候是不需要自己去做同步工作的。更方便也更不容易出错，
2，如果Synchronized在我们的程序中适用，就优先使用Synchronized。这样可以减少我们所需要编写的代码，减少了出错的几率。
3，如果特别需要用到Lock或者Condition独有的特性的时候，才使用Lock或者Condition。
三、思考题
1，在多个线程获取同一个Synchronized锁的时候，JVM如何选择下一个获取锁的是哪个线程？
内部锁调度机制，一个持有锁的线程在运行结束或者抛出异常后就会释放这把锁，这时候有哪些人会来竞争这把锁呢？除了刚才已经在等待的那些线程之外，也有可能是刚刚进入Synchronized代码块的处于Runnable的线程，他刚进来没来得及进入Block人家就把锁释放掉。所以一共会有Block状态和Runnable状态的线程来竞争这把锁，而在竞争的时候，是被JVM虚拟机的实现来左右的，也就是说谁能获取到这把锁，是处于一种不公平的状态的，有可能是等待时间最长的线程，也有可能是等待时间最短的线程，或者是随机的。这个细节和JVM的版本以及实现都有关系，所以不能依赖这个算法，我们只能判定这是一个随机不可控制的过程。
2，Synchronized使得同时只有一个线程可以执行，性能较差，有什么方法可以提升性能？
优化使用范围，在符合要求的情况下尽量减少作用域。
可以使用其他类型的Lock，如读写锁
3，我想更灵活地控制锁的获取和释放（现在释放锁的时机都被规定死了），怎么办？
自己实现自己的Lock interface。完全控制锁的获取和释放。参考已有的优秀的实现。
4，什么是锁的升级、降级？什么是JVM里的偏斜锁、轻量级锁、重量级锁？
在JVM之前的版本中Synchronized的性能不是特别好，经过不断迭代，已经得到显著提高，这里面的迭代就是利用偏斜锁、轻量级锁、重量级锁，JVM会根据Synchronized关键字所使用到的次数或者其他的种种指标来对这个锁进行非常有效的优化，使得性能得到大幅度的上涨，涉及到对象头（header word）里面的一些字段，值得深入研究。
网友评论