sychronized底层原理探秘
Synchronized作用：
官方解释：同步方法支持一种简单的策略来防止线程干扰和内存一致性错误：如果一个对象对多个线程可见，则对该对象变量的所有读取或写入都是通过同步方法完成的。
一句话总结出Synchronized的作用：
能够保证在同一时刻最多只有一个线程执行该段代码，以达到保证并发安全的效果
synchronized的底层原理及其实现：
代码结合模型分析的更加透彻
场景：模拟双十一秒杀活动，数据库一共有5条数据，使用JMeter模拟30个线程同时访问以下程序，结果是什么
@Service
public class SychronizedTest {
private static Object object=new Object();
public String decStockNoLock(){
Integer stock ;
synchronized (object){
List<Map> result=jdbcTemplate.query("select stock from shop_order where id=10");
if(result==null||(stock=(Integer)result.get(0).get("stock"))<=0){
logger.info("下单失败，已经没有库存了");
return "下单失败，已经没有库存了";
}
stock--;
jdbcTemplate.update("update shop_order set stock=? where stock=1",stock);
logger.info("下单成功，当前剩余产品数------>"+stock);
}
return "下单成功，当前剩余产品数------>"+stock;
}
}
假设我们没有加synchronized关键字修饰代码块，那么这30个线程都会下单成功。如果加了synchronized后则只有几个线程会下单成功。为什么呢？
三条了逻辑操作语句如下：
1 List<Map> result=jdbcTemplate.query("select stock from shop_order where id=10");
2 stock--;
3 jdbcTemplate.update("update shop_order set stock=? where stock=1",stock);
不加锁：
先上图：
最开始主存里面的stack=5，三个线程获取到了这个stack变量，将他们拷贝到自己的工作内存中，对stack进行stack–操作，此时三个线程将自己工作内存的stack变量通过原子操作store和write同步到主内存.此时bug就发生了，明明三个线程都对stack变量进行了stack–操作，此时的stack应该是2才对。
上述方法不是同步方法，可能线程1执行了第二行逻辑代码，线程2执行了第三行逻辑代码，线程3又执行了第一行逻辑代码，那么就会导致数据的不一致性。
加锁：
给需要同步的代码块加上synchronized关键字就可以避免这一现象，为什么呢？如果是官方给的解释，那等于值告诉我们是什么，没告诉我们为什么。
先从Java内存模型分析：
还是先上图：
首先线程1获取到了Object对象的锁，此时JVM会通过lock原子操作给Object对象加一个锁。其他的线程对这个对象无法读，无法写，其他的线程进行阻塞，进入阻塞队列。直到线程1，做完了按照原子操作的顺序完成操作，释放锁。然后会唤醒其他因为等待这个锁释放而进入阻塞队列的线程。（注意：是等待这个锁而进入阻塞队列的线程，而不是其它阻塞队列的线程）
再从字节码的执行分析：
还是先上图：
我们分析了Java执行的字节码文件，发现在执行逻辑的前面有一个monitorenter在执行逻辑的后面有一个monitorenterexit.如上图，每一个对象在创建的时候，JVM就会给它匹配一个Monitor对象。
解释了monitor对象，我们就来解释moniter的是实现原理：
JVM内置锁通过synchronized的使用，通过内置对象Monitor（监视器锁）实现，基于进入和退出Monitor对象实现方法和代码块同步，监视器的锁的实现依赖操作系统的底层Mutex Lock（互斥锁）来实现，是一个重量级锁，性能较低。
原理如下图：
通过以上2中方法分析，应该已经很清楚了synchronized的底层原理
