前言
在并发编程中，多个线程对同一资源进行操作，必然会出现资源竞争的情况,那么要保证线程间的对同一资源的访问，就需要一个信号来标志
当前哪个线程可以使用该资源，在某一线程使用该资源期间，其他线程都不能对该资源进行操作，不然可能会出现无法预料的错误。
那我们要使线程间对同一资源进行互斥操作，也就是需要锁住这个操作周期，保证同一时间只有一个线程能访问并使用该资源，我们就需要有
一系列的操作来控制这个访问方式。也就是俗称的加锁处理
加锁的实现
JDK提供了一系列的加锁方式，比如synchronized同步原语来保证代码块的互斥访问、ReentrantLock等类提供加锁方式。
那如果在不使用jdk提供的加锁方式时，我们如何实现一个自己的锁呢？
加锁原理
上面说了，加锁实际就是需要一个信号来标志该锁是否被人持有，如果没有，那么我就可以用，如果被他人持有了，那么我就不能使用，得等他人使用完我才可以用。
那我的思路就来了，定义一个互斥量，有人能拿到我就改个值，让其他人没法拿，用完后我再改回去，好 现在开干。
public class Main {//0 是无人持有，1 是有人持有static int mutex = 0;static void lock(){while(mutex != 0){}mutex = 1;}static void unlock(){mutex = 0;}//测试多线程累加计数static int i = 0;public static void main(String[] args) throws InterruptedException {for(int x = 1; x <= 1000; x++){new Thread(()->{try{Main.lock();i++;}finally {Main.unlock();}}).start();}//主线程睡眠是需要等待子线程完成，用睡眠不一定保证睡眠时间到的时候子线程都执行完了，不过这里的场景预计是可以满足的，//这里只做演示，后面用信号量来实现线程间通信可以保证主线程等待所有子线程完成才执行Thread.sleep(3000);System.out.println(i);}
}
上面代码我使用mutex变量表示互斥信号量(也就是锁)，0表示锁无人持有，1表示已经有人持有。
加锁方法lock()的时候先进来的线程判断mutex是否为被人持有，如果是，那么线程自旋，等待其他线程释放锁；
如果没被人持有，那么更改mutex为1，表示该锁已经被我使用.用完后用unlock()方法把mutex改为无人持有。
如果这个锁是实现正确的,那么最后输出的结果i是1000。
但是,很抱歉，上述代码是有问题的,并不是每次执行都是输出的1000。第一, mutex和i只是静态变量，虽然主内存中只有唯一一份，但是不同的线程内部使用的时候会有一份缓存,
如果变量被改动了，但是线程中的缓存还是旧值，那变量的值就没有同步到线程里;第二，多个线程有可能会同时进入while判断，大家
有可能获取到的都是mutex=0,那都会拿到锁，这样的话没有达到线程间互斥，加锁就是失败的。
现在针对以上问题我们进行改造，引入java的volatile修饰词，在修饰变量时主要有两个作用，一是保证变量在内存中的可见性，也就是在多个线程对其
进行读写的时候，都会在主存中进行，如果这个变量被一个线程改动了，那么其值会刷到主存中，其他线程读取的也是主存中最新的值；二是禁止
指令重排序。并且volatile不保证原子性，关于volatile修饰词的详细解释可以参考其他资料。
只加volatile也没法保证多个线程不会同时进入while的条件判断， 那我们有什么办法可以保证同时只有一个线程满足呢?
如果有一个原子操作能将mutex修改为1的同时能返回之前mutex的旧值，那我们就可以完成一个锁了。当然，光靠java本身也是没法实现
这一操作的，但是好在硬件给我们提供了该行为的原子操作，使得java可以提供相关接口来实现。
基于getAndSet原子操作实现的简单锁
AtomicInteger.getAndSet(int newValue): 给变量设置新的值，返回旧的值
伪代码:
AtomicInteger ai = new AtomicInteger();
//这整个方法都是原子性操作，虽然看上去是有多条指令，但在硬件的支持下 ，这个操作就是原子的，要么执行要么不执行，而不会出现执行到一半不执行或执行到一半出错
int getAndSet(int newValue){int oldValue = ai.value;ai.value = newValue;return oldValue
}
import java.util.concurrent.atomic.AtomicInteger;
public class Main {//0 是无人持有，1 是有人持有static AtomicInteger mutex = new AtomicInteger(0);static void lock(){while(mutex.getAndSet(1) == 1){}}static void unlock(){mutex.set(0);}//测试多线程累加计数static volatile int i = 0;public static void main(String[] args) throws InterruptedException {for(int x = 1; x <= 1000; x++){new Thread(()->{try{Main.lock();i++;}finally {Main.unlock();}}).start();}Thread.sleep(3000);System.out.println(i);}
}
上面使用getAndSet实现的锁已经可以满足正常的单应用内的加锁互斥功能,
不过这样写还是有问题的,我们虽然可以保证线程间互斥了，但是在锁被持有期间，
其他线程都在while循环，占用CPU时间一直自旋，浪费很多CPU周期，这不拜拜浪费资源、影响其他进程运行吗？
还有问题就是，这个锁我们可以发现，由于线程的调度是由操作系统管理的，我们并无法预知下一个获取到锁的
线程，那么有没有可能一直处于多线程竞争中的时候，会有某个或者某些线程长时间无法拿到锁呢？
答案是有可能的，我们应用自身无法管理线程调度，那上面的加锁代码就确实有可能造成某些竞争中的线程
长时间拿不到锁。基于这个锁的两个问题特点，那我们就把他叫做为非公平自旋锁吧
为解决公平性问题产生的公平锁
那为了让竞争的线程都有同样的机会拿到锁，保证大家的公平性，那我就是要知道当前的线程执行后，需要把锁给下一个等待的兄弟嘛。
那我让竞争的线程按先来先得的套路排个队就得了呗？ 没错，正是这样的
那为了有个排队的机制，我直接把线程用个链表串起来就完事儿了呗，上一个节点执行完，通知下一个节点执行？
道理是这个道理，但是直接跳到这步那不是和我们日常使用的jdk中的ReentrantLock差不多啦？
对的，ReentrantLock就是在这些基础上，稍微做亿点点修改就成为了jdk中的常用的加锁方式啦。
但是我们步子稍微迈小一点，假设我不知道什么叫ReentrantLock,也从未接触过什么抽象队列同步器(如果真没去接触过，那么忽略掉这句话)。
先看如何能够解决公平性问题，也就是大家都按顺序来获取锁
还是从原子类AtomicInteger入手(有很多方式，我们这里只看这个最简单的),里面提供一个原子操作，叫做getAndIncrement(),可以将变量加1，然后返回之前的旧值
既然要让线程排序，那每个线程自身就需要持有一个标记，表示他应该是第几个开始执行的或者说他排在队列中的哪个位置
着重关注这两个方法:
- getAndIncrement()
将当前变量的值自增1，并返回变量之前的值
伪代码:
AtomicInteger ai = new AomicInteger();
int getAndIncrement(){int oldValue = ai.value;ai.value++;return oldValue;
}
2.incrementAndGet()
将当前变量的值自增1，并返回自增后新的值
伪代码:
AtomicInteger ai = new AomicInteger();
int incrementAndGet(){return ++ai.value;
}
public class GetAndAddLock {Mutex mutex;class Mutex{AtomicInteger threadOrder = new AtomicInteger(0);AtomicInteger turn = new AtomicInteger(0);}public GetAndAddLock(){mutex = new Mutex();}public void lock(){int currentThreadOrder = mutex.threadOrder.getAndIncrement();while(currentThreadOrder != mutex.turn.get()){}}public void unlock(){mutex.turn.incrementAndGet();}}
可以看到上面的GetAndLock类，内部有个Mutex类，Mutex的threadOrder和turn是实现线程顺序执行的关键.
举个例子，假如有两个线程T1、T2、T3同时开始执行lock方法,
mutex.threadOrder.getAndIncrement();三个线程肯定有个先后顺序执行这个原子操作，假设这个原子类的执行顺序为T1、T2、T3
假设T1先执行，那么T1的currentThreadOrder的值为0，mutex.threadOrder这个时候为1，为0,
然后T2执行后,T2的currentThreadOrder就为1，mutex.threadOrder就变为了2，mutex.turn为0,
T3执行后,T3的currentThreadOrder为2，mutex.threadOrder为3,mutex.turn为0,
然后T1、T2、T3都进入了while判断，这个时候只有T1满足跳出循环的条件能获取锁，T2、T3一直自旋等待,
当T1执行完后，T1线程将mutex.turn自增1后值变为1，那么自旋等待中的T2、T3线程中，只有T2能满足跳出循环的条件，T3则继续等待。
这样就能保证线程执行getAndIncrement的顺序一定是线程获取锁执行的顺序，这样的方式可以不使用额外的队列、链表之类的结构
就能达到线程按到达时间顺序执行的效果
解决自旋问题带来的资源浪费和性能下降问题
上面的锁我们把公平性问题解决了，但是等待获取锁的线程一直在while死循环，那这种锁设计也还是不完美。
那我们可以让自旋中的线程把CPU让出来吗？
答案是可以的，线程提供yield方法可以让出当前的CPU调度，这样在CPU当前时间片调度到该线程时，可以让出当次的CPU使用权，
不过我们在while循环中，这次让出了，那下次再执行循环的时候就会出现线程反复被调度然后反复让出自己的时间片，这样的方案
依然成本很高，频繁的上下文切换也是在浪费资源。
那么我们还可以怎么做呢？
我们知道线程的状态中有个等待状态，那我们让线程进入等待状态，不是就绪状态，那CPU不就不调度他了吗，只需要我们在需要调度的时候
唤醒它，那剩余时间它不就自己默默在某个阴凉处默默无闻无人关注吗?
LockSupport提供一组睡眠和唤醒的操作，分别是LockSupport.park()和LockSupport.unpark(Thread),
park可以让当前线程进入等待状态/休眠而不参与CPU的调度，unpark(Thread)可以唤醒一个线程让他继续参与CPU调度。
那当前线程休眠后需要由其他线程唤醒，那这个其他线程就需要知道该唤醒哪一个线程
基于上面的条件，我们重新构造一个新的锁实现
public class SimpleFairLock {//标志是否锁被持有，0表示未被持有，1表示已被持有AtomicInteger mutex = new AtomicInteger();//标志是否有线程在进行加锁或解锁操作，0表示没有，1表示有AtomicInteger lockingThread = new AtomicInteger();//当成队列使用，存储等待的线程ArrayList<Thread> queue = new ArrayList<>();public void lock(){while(lockingThread.getAndSet(1) == 1);if(mutex.get() == 0){mutex.set(1);lockingThread.set(0);}else{queue.add(Thread.currentThread());lockingThread.set(0);LockSupport.park();}}public void unlock(){while(lockingThread.getAndSet(1) == 0);if(queue.isEmpty()){mutex.set(0);}else{Thread nextWaiter = queue.remove(0);LockSupport.unpark(nextWaiter);}lockingThread.set(0);}}
上面的代码实现虽然还有性能问题存在，但是已经是一个简单的公平锁了。
把数组集合queue当成队列使用,用于存储按顺序lock时加入的线程;
虽然上面代码还有while在自旋，但是自旋次数已经变少了，仅仅只在有线程进行加解锁操作的时候会自旋,
加锁成功的线程本身处理业务时等待线程是不会再自旋的。
最重要的就是lockingThread和mutex变量，可以看到，lockingThread就是防止加解锁过程中产生竞争的条件,
尽管ArrayList不是线程安全的集合,但有了lockingThread这个变量维持的操作后,我们让其变成加解锁
内部的ArrayList操作也变成了安全的操作。
而mutex变量就是为了判定当前锁是否被人持有，如果持有，那当前加锁的线程就需要睡眠。
并且可以看到上面的queue在mutex被持有的时候才进行入队操作，只有队列为空的时候才标记mutex为空闲，
也就是说在没有线程在等待的时候,就没有等待者需要被唤醒，即使这个时候有很多线程进来，那他们也会自旋进行抢占入队的顺序。
以上为个人对锁机制一些简单的理解。
有了这些较为基础的加锁方式后，再去看AQS及其实现类就会很清晰。