synchronized的特性
1.互斥
对于synchronized修饰的方法及代码块不同线程想同时进行访问就会互斥。
就比如synchronized修饰代码块时，一个线程进入该代码块就会进行“加锁”。
退出代码块时会进行“解锁”。
当其他线程想要访问被加锁的代码块时，就会阻塞等待。
阻塞等待：
针对每⼀把锁, 操作系统内部都维护了⼀个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进⾏加锁, 就加不上了, 就会阻塞等待, ⼀直等到之前的线程解锁之后, 由操作系统唤醒⼀个新的线程,再来获取到这个锁
这就好比在公共厕所上厕所一个人进去之后把门关上并加锁，其他人就不能进来要在外面等待，等到里面的人把锁打开出来之后，大家才能共同竞争，而且这个等待过程是不按顺序的，就是你先来的话，这个打开的时候也不一定是你先进入这个厕所，也就是因为是抢占式执行的原因。
还有：
上⼀个线程解锁之后, 下⼀个线程并不是⽴即就能获取到锁. ⽽是要靠操作系统来 "唤醒". 这也就是操作系统线程调度的⼀部分⼯作
只有在上完厕所的人大喊一声“我上完了，你们可以进来了”，别人才能进来，而不是把门打开之后别人就立马进去 。
同样当synchronized对方法进行修饰的时候也是像代码块一样，
并且都把锁对象的信息储存在该对象的对象头中
可以粗略理解成, 每个对象在内存中存储的时候, 都存有⼀块内存表⽰当前的 "锁定" 状态(类似于厕所的 "有⼈/⽆⼈").
如果当前是 "⽆⼈" 状态, 那么就可以使⽤, 使⽤时需要设为 "有⼈" 状态.
如果当前是 "有⼈" 状态, 那么其他⼈⽆法使⽤, 只能排队
2.可重入
synchronized修饰的代码有可重入的特性，不会发生“死锁”。
死锁：
自己已经完成加锁工作了，这个锁已经处于被占用的状态了，自己却想要再次进行二次加锁，但是由于前项规定这个锁只能由他自己释放，这个锁没有被释放，无法加锁，导致死锁。
Java 中的 synchronized 是 可重⼊锁, 因此没有上⾯的问题
在可重入锁的内部记录锁的持有者和计数器的信息
如果这个对象在一次加锁之后，在一次加锁之后计数器由零变成一，此时还想进行二次加锁就会先判断这个锁的持有者是不是自己，如果是自己的话就允许再次加锁，并将计数器中的数字改成二，表示着加了两次锁。
如果要释放锁的话就会将计数器中的数字一直减到零才释放，此时才能被别的线程捕获到。
3.内存可见性
从结果上看，synchronized解决了内存可见性的问题，因为强制要求在锁释放后才能被其他线程感知调用，结果上实现了内存可见性。