由于使用场景的不同，我们的锁有许多不同的分类
乐观锁就是觉得程序锁冲突的概率不高，因此设计的锁没那么复杂
悲观锁就是觉得程序锁冲突的概率很高，因此就让锁实现的更好，避免冲突
乐观锁由于没那么多冲突，因此代码的效率就会提升，但是相对应的数据的准确度就会下降
普通互斥锁就和synchronized一样，只要同时访问就会竞争
读写锁有两把锁，读锁和写锁
当读锁和读锁同时访问一个数据，不会发生竞争
当读锁和写锁同时访问一个数据，会发生竞争
当写锁和写锁同时访问一个数据，会发生竞争
因此，读写锁相比于普通互斥锁少了很多竞争，也就提升了效率
轻量级锁的加锁和解锁的开销小，例如纯用户态的加锁
重量级锁的加锁和解锁的开销大，例如用户态和内核态切换的加锁
和我们刚才讲的乐观锁和悲观锁对比，重量级锁轻量级锁主要描述的是锁的加锁解锁消耗的时间和资源，而乐观锁悲观锁主要说的是加锁解锁中干的工作多不多
而乐观锁一般就是轻量级锁，悲观锁一般是重量级锁
自旋锁是在锁冲突阻塞等待时，反复询问当前锁是否就绪，这样的话如果解锁了就可以第一时间获得锁
挂起等待锁则是在这个等待时间中可以去干一点别的事情，这样的话可能会错过锁
自旋锁尽管看起来消耗了很多资源，但是是轻量级锁，因为自选锁减少了线程的挂起和恢复，这是由用户态到内核态的过程
公平锁就是在锁竞争后，按照先来后到获取锁
而非公平锁就是锁竞争后，几个线程重新竞争锁
类似于懒汉模式，能不加锁就不加锁，当没有锁冲突时就不加锁，一旦发生冲突了，就在发生冲突的代码段上加锁
当JVM判定我们的代码有的地方是不用加锁的，就会把这个锁去掉，比如虽然有多个线程，但并不修改同一个变量
这种优化是编译器有十足把握才会优化的
锁中的代码数量代表锁的粒度，粒度越粗，代码越多
锁粗化就是一个让锁粒度变粗的操作
当我们对一段连续的代码段，同时用一个锁对象多次加锁，我们的synchronized就会自动把这些锁合并成一个，减少了连续加锁解锁的资源消耗
当然，锁粒度不是越粗越好，既要保证实现的逻辑，也要保证效率
英文全称是compare and swap，也就是比较并交换
将内存中的值和寄存器A的进行比较，如果一样就把寄存器B的值和内存中的值进行交换
由于CAS是CPU指令完成的，因此这个过程是原子的，也就不会涉及到锁冲突，也十分高效，因此我们可以在一些场景下用CAS来代替加锁
我们将各个数据类型的前置++，后置++，前置–，后置–等操作封装起来的类就是原子类，这种类在多线程下是线程安全的，并且十分高效
class AtomicInteger {
private int value;
public int getAndIncrement() {
int oldValue = value;
while ( CAS(value, oldValue, oldValue+1) != true) {
oldValue = value;
}
return oldValue;
}
}
这个CAS方法中的参数，第一个参数value就相当于内存中的值，第二个oldvalue则是寄存器1中的值，oldvalue + 1则是寄存器2中的值。在自增方法中，先循环判断内存中的值和寄存器1中的值是否相同，如果相同就把寄存器b中的值给内存，也就实现了自增操作，如果不同，oldvalue将赋值为新的value操作。
实际操作中，有1和2两个线程，1线程先加载内存中的值，然后2线程也加载内存中的值，然后内存1CAS操作将内存中的值加一，2线程再进行CAS操作时就会发现自己加载的值和内存中的值不一样了，于是重新加载内存中的值，然后再进行加加操作，这样就避免了线程不安全
public static void main(String[] args) throws InterruptedException {
AtomicInteger count = new AtomicInteger(0);
Thread t1 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
count.getAndIncrement();
// count.incrementAndGet();
// count.getAndDecrement();
// count.decrementAndGet();
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < 50000; i++) {
count.getAndIncrement();
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(count);
}
getAndIncrement() 后置加加
incrementAndGet() 前置加加
getAndDecrement() 后置减减
decrementAndGet() 前置减减
另外还有其他数据类型的类
AtomicBoolean
AtomicInteger
AtomicIntegerArray
AtomicLong
AtomicReference
AtomicStampedReference
public class SpinLock {
private Thread owner = null;
public void lock(){
while(!CAS(this.owner, null, Thread.currentThread())){
}
}
public void unlock (){
this.owner = null;
}
}
在加锁过程中判断锁的持有者是不是空，如果是，就将锁的持有者变成自己，否则就一直判断，直到锁的持有者变成空
也就是CAS操作无法分辨出内存中的值是不是改变了之后又改变回来了
假设我去取钱，银行取钱时用CAS来对账户余额进行更改操作。，本来账户有1000块，由于atm卡了，我按了两次取800的操作。这时就会创建出两个线程进行CAS操作，两个线程的CAS都从我账户余额中读到了1000的原始余额，a线程先让账户减少了800，这时有别人给我转了800，我的账户余额就又变成1000了，这时b线程就觉得我的账户还没有进行减余额的操作，于是又给我减了800块
我们不直接对账户余额使用CAS进行更改，而是用一个新的变量——版本号，当我们操作一次余额就增加一次版本号，原本版本号是1，a线程和b线程都读到这个版本号，a线程先让版本号变成2，然后存钱的操作让版本号变成了3，这样b线程就会发现版本号和自己读取到的不一样，就会重新读取