乐观锁：每次取数据的时候，都会认为别人不会修改，更新的时候会看一下这个期间内是否有人更新这个数据，java最常用的是CAS算法，java中原子类就是利用这个算法（CAS全称 Compare And Swap（比较与交换））是一种无锁算法。在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。java.util.concurrent包中的原子类就是通过CAS来实现了乐观锁。三步走：需要读写的内存知V 进行比较的值A 要写入的值B 且仅当预期值A和内存值V相同时，将内存值V修改为B，否则返回V。这是一种乐观锁的思路，它相信在它修改之前，没有其它线程去修改它；而Synchronized是一种悲观锁，它认为在它修改之前，一定会有其它线程去修改它，悲观锁效率很低。 ———————————————————————————————————————————— 悲观锁：总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁。（典型悲观锁synchronized）传统的MySQL关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。详情可以参考：阿里P8架构师谈：MySQL行锁、表锁、悲观锁、乐观锁的特点与应用

：悲观锁适合写操作多的地方，先加锁保证写操作数据的正确性

乐观锁适合读操作多的地方，不加锁读的性能大幅提升 —————————————————————————————————————————————— 公平锁就是很公平，在并发环境中，每个线程在获取锁时会先查看此锁维护的等待队列，如果为空，或者当前线程是等待队列的第一个，就占有锁，否则就会加入到等待队列中，以后会按照FIFO的规则从队列中取到自己。公平锁的优点是等待锁的线程不会饿死。缺点是整体吞吐效率相对非公平锁要低，等待队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大。

非公平锁上来就直接尝试占有锁，如果尝试失败，就再采用类似公平锁那种方式。　　非公平锁的优点是可以减少唤起线程的开销，整体的吞吐效率高，因为线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程。缺点是处于等待队列中的线程可能会饿死，或者等很久才会获得锁。

典型应用 java jdk并发包中的ReentrantLock可以指定构造函数的boolean类型来创建公平锁和非公平锁（默认）,比如：公平锁可以使用new ReentrantLock(true)实现。

独享锁是指该锁一次只能被一个线程所持有。

共享锁是指该锁可被多个线程所持有。

比较对于Java ReentrantLock而言，其是独享锁。但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。　　读锁的共享锁可保证并发读是非常高效的，读写，写读，写写的过程是互斥的。　　独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

AQS 抽象队列同步器（AbstractQueuedSynchronizer，简称AQS）是用来构建锁或者其他同步组件的基础框架，它使用一个整型的volatile变量（命名为state）来维护同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作。

高层类：Lock 同步器阻塞队列 Executor 并发容器基础类：AQS 非阻塞数据结构源自变量类 volatile变量的读/写 CAS concurrent包的实现结构如上所示，AQS、非阻塞数据结构和原子变量类等基础类都是基于volatile变量的读/写和CAS实现，而像Lock、同步器、阻塞队列、Executor和并发容器等高层类又是基于基础类实现。

分段锁分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。　　我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7与JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock)。　　当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。　　但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。　　分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。 —————————————————————————————————————————————— Java线程锁多线程的缘由在出现了进程之后，操作系统的性能得到了大大的提升。虽然进程的出现解决了操作系统的并发问题，但是人们仍然不满足，人们逐渐对实时性有了要求。　　使用多线程的理由之一是和进程相比，它是一种非常花销小，切换快，更”节俭”的多任务操作方式。在Linux系统下，启动一个新的进程必须分配给它独立的地址空间，建立众多的数据表来维护它的代码段、堆栈段和数据段，这是一种”昂贵”的多任务工作方式。而在进程中的同时运行多个线程，它们彼此之间使用相同的地址空间，共享大部分数据，启动一个线程所花费的空间远远小于启动一个进程所花费的空间，而且，线程间彼此切换所需的时间也远远小于进程间切换所需要的时间。

多线程并发面临的问题由于多个线程是共同占有所属进程的资源和地址空间的，那么就会存在一个问题：如果多个线程要同时访问某个资源，怎么处理？　　在Java并发编程中，经常遇到多个线程访问同一个共享资源，这时候作为开发者必须考虑如何维护数据一致性，这就是Java锁机制(同步问题)的来源。　　 Java提供了多种多线程锁机制的实现方式，常见的有：

synchronized ReentrantLock Semaphore AtomicInteger等　　每种机制都有优缺点与各自的适用场景，必须熟练掌握他们的特点才能在Java多线程应用开发时得心应手。

4种Java线程锁(线程同步) 1.synchronized 在Java中synchronized关键字被常用于维护数据一致性。synchronized机制是给共享资源上锁，只有拿到锁的线程才可以访问共享资源，这样就可以强制使得对共享资源的访问都是顺序的。　　 Java开发人员都认识synchronized，使用它来实现多线程的同步操作是非常简单的，只要在需要同步的对方的方法、类或代码块中加入该关键字，它能够保证在同一个时刻最多只有一个线程执行同一个对象的同步代码，可保证修饰的代码在执行过程中不会被其他线程干扰。使用synchronized修饰的代码具有原子性和可见性，在需要进程同步的程序中使用的频率非常高，可以满足一般的进程同步要求。 synchronized (obj) { //方法 ……. } synchronized实现的机理依赖于软件层面上的JVM，因此其性能会随着Java版本的不断升级而提高。到了Java1.6，synchronized进行了很多的优化，有适应自旋、锁消除、锁粗化、轻量级锁及偏向锁等，效率有了本质上的提高。在之后推出的Java1.7与1.8中，均对该关键字的实现机理做了优化。需要说明的是，当线程通过synchronized等待锁时是不能被Thread.interrupt()中断的，因此程序设计时必须检查确保合理，否则可能会造成线程死锁的尴尬境地。最后，尽管Java实现的锁机制有很多种，并且有些锁机制性能也比synchronized高，但还是强烈推荐在多线程应用程序中使用该关键字，因为实现方便，后续工作由JVM来完成，可靠性高。只有在确定锁机制是当前多线程程序的性能瓶颈时，才考虑使用其他机制，如ReentrantLock等。

2.ReentrantLock 可重入锁，顾名思义，这个锁可以被线程多次重复进入进行获取操作。　　 ReentantLock继承接口Lock并实现了接口中定义的方法，除了能完成synchronized所能完成的所有工作外，还提供了诸如可响应中断锁、可轮询锁请求、定时锁等避免多线程死锁的方法。 Lock实现的机理依赖于特殊的CPU指定，可以认为不受JVM的约束，并可以通过其他语言平台来完成底层的实现。在并发量较小的多线程应用程序中，ReentrantLock与synchronized性能相差无几，但在高并发量的条件下，synchronized性能会迅速下降几十倍，而ReentrantLock的性能却能依然维持一个水准。因此我们建议在高并发量情况下使用ReentrantLock。 ReentrantLock引入两个概念：公平锁与非公平锁。公平锁指的是锁的分配机制是公平的，通常先对锁提出获取请求的线程会先被分配到锁。反之，JVM按随机、就近原则分配锁的机制则称为不公平锁。 ReentrantLock在构造函数中提供了是否公平锁的初始化方式，默认为非公平锁。这是因为，非公平锁实际执行的效率要远远超出公平锁，除非程序有特殊需要，否则最常用非公平锁的分配机制。 ReentrantLock通过方法lock()与unlock()来进行加锁与解锁操作，与synchronized会被JVM自动解锁机制不同，ReentrantLock加锁后需要手动进行解锁。为了避免程序出现异常而无法正常解锁的情况，使用ReentrantLock必须在finally控制块中进行解锁操作。通常使用方式如下所示： Lock lock = new ReentrantLock(); try { lock.lock(); //…进行任务操作5 }finally { lock.unlock(); }

3.Semaphore 上述两种锁机制类型都是“互斥锁”，学过操作系统的都知道，互斥是进程同步关系的一种特殊情况，相当于只存在一个临界资源，因此同时最多只能给一个线程提供服务。但是，在实际复杂的多线程应用程序中，可能存在多个临界资源，这时候我们可以借助Semaphore信号量来完成多个临界资源的访问。　　 Semaphore基本能完成ReentrantLock的所有工作，使用方法也与之类似，通过acquire()与release()方法来获得和释放临界资源。　　经实测，Semaphone.acquire()方法默认为可响应中断锁，与ReentrantLock.lockInterruptibly()作用效果一致，也就是说在等待临界资源的过程中可以被Thread.interrupt()方法中断。　　此外，Semaphore也实现了可轮询的锁请求与定时锁的功能，除了方法名tryAcquire与tryLock不同，其使用方法与ReentrantLock几乎一致。Semaphore也提供了公平与非公平锁的机制，也可在构造函数中进行设定。 Semaphore的锁释放操作也由手动进行，因此与ReentrantLock一样，为避免线程因抛出异常而无法正常释放锁的情况发生，释放锁的操作也必须在finally代码块中完成。

4.AtomicInteger 首先说明，此处AtomicInteger是一系列相同类的代表之一，常见的还有AtomicLong等，他们的实现原理相同，区别在与运算对象类型的不同。　　我们知道，在多线程程序中，诸如++i 或i++等运算不具有原子性，是不安全的线程操作之一。通常我们会使用synchronized将该操作变成一个原子操作，但JVM为此类操作特意提供了一些同步类，使得使用更方便，且使程序运行效率变得更高。通过相关资料显示，通常AtomicInteger的性能是ReentantLock的好几倍。

Java线程锁总结 1.synchronized：在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好。 2.ReentrantLock: 在资源竞争不激烈的情形下，性能稍微比synchronized差点点。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍，而ReentrantLock确还能维持常态。高并发量情况下使用ReentrantLock。 3.Atomic: 和上面的类似，不激烈情况下，性能比synchronized略逊，而激烈的时候，也能维持常态。激烈的时候，Atomic的性能会优于ReentrantLock一倍左右。但是其有一个缺点，就是只能同步一个值，一段代码中只能出现一个Atomic的变量，多于一个同步无效。因为他不能在多个Atomic之间同步。所以，我们写同步的时候，优先考虑synchronized，如果有特殊需要，再进一步优化。ReentrantLock和Atomic如果用的不好，不仅不能提高性能，还可能带来灾难。以上就是Java线程锁的详解，除了从编程的角度应对高并发，更多还需要从架构设计的层面来应对高并发场景，例如：Redis缓存、CDN、异步消息等。

原文：https://blog.csdn.net/u013030086/article/details/85001354

AQS （AbstractQueuedSynchronizer）什么是AQS AQS(AbstractQueuedSynchronizer)，AQS是JDK下提供的一套用于实现基于FIFO等待队列的阻塞锁和相关的同步器的一个同步框架。这个抽象类被设计为作为一些可用原子int值来表示状态的同步器的基类。如果你有看过类似 CountDownLatch 类的源码实现，会发现其内部有一个继承了 AbstractQueuedSynchronizer 的内部类 Sync 。可见 CountDownLatch 是基于AQS框架来实现的一个同步器.类似的同步器在JUC下还有不少。(eg. Semaphore ) AQS用法如上所述，AQS管理一个关于状态信息的单一整数，该整数可以表现任何状态。比如， Semaphore 用它来表现剩余的许可数，ReentrantLock 用它来表现拥有它的线程已经请求了多少次锁；FutureTask 用它来表现任务的状态(尚未开始、运行、完成和取消)

如JDK的文档中所说，使用AQS来实现一个同步器需要覆盖实现如下几个方法，并且使用getState,setState,compareAndSetState这几个方法来设置获取状态

boolean tryAcquire(int arg) boolean tryRelease(int arg) int tryAcquireShared(int arg) boolean tryReleaseShared(int arg) boolean isHeldExclusively() 以上方法不需要全部实现，根据获取的锁的种类可以选择实现不同的方法，支持独占(排他)获取锁的同步器应该实现tryAcquire、 tryRelease、isHeldExclusively而支持共享获取的同步器应该实现tryAcquireShared、tryReleaseShared、isHeldExclusively。下面以 CountDownLatch 举例说明基于AQS实现同步器, CountDownLatch 用同步状态持有当前计数，countDown方法调用 release从而导致计数器递减；当计数器为0时，解除所有线程的等待；await调用acquire，如果计数器为0，acquire 会立即返回，否则阻塞。通常用于某任务需要等待其他任务都完成后才能继续执行的情景。源码如下: public class CountDownLatch { /**

基于AQS的内部Sync
使用AQS的state来表示计数count. */ private static final class Sync extends AbstractQueuedSynchronizer { private static final long serialVersionUID = 4982264981922014374L;
```
Sync(int count) {
    // 使用AQS的getState()方法设置状态
    setState(count);
}

int getCount() {
    // 使用AQS的getState()方法获取状态
    return getState();
}

// 覆盖在共享模式下尝试获取锁
protected int tryAcquireShared(int acquires) {
    // 这里用状态state是否为0来表示是否成功，为0的时候可以获取到返回1，否则不可以返回-1
    return (getState() == 0) ? 1 : -1;
}

// 覆盖在共享模式下尝试释放锁
protected boolean tryReleaseShared(int releases) {
    // 在for循环中Decrement count直至成功;
    // 当状态值即count为0的时候，返回false表示 signal when transition to zero
    for (;;) {
        int c = getState();
        if (c == 0)
            return false;
        int nextc = c-1;
        if (compareAndSetState(c, nextc))
            return nextc == 0;
    }
}
```
}

private final Sync sync;

// 使用给定计数值构造CountDownLatch public CountDownLatch(int count) { if (count < 0) throw new IllegalArgumentException("count < 0"); this.sync = new Sync(count); }

// 让当前线程阻塞直到计数count变为0，或者线程被中断 public void await() throws InterruptedException { sync.acquireSharedInterruptibly(1); }

// 阻塞当前线程，除非count变为0或者等待了timeout的时间。当count变为0时，返回true public boolean await(long timeout, TimeUnit unit) throws InterruptedException { return sync.tryAcquireSharedNanos(1, unit.toNanos(timeout)); }

// count递减 public void countDown() { sync.releaseShared(1); }

// 获取当前count值 public long getCount() { return sync.getCount(); }

public String toString() { return super.toString() + "[Count = " + sync.getCount() + "]"; } } —————————————————————————————————————————————— AQS实现原理浅析 AQS的实现主要在于维护一个volatile int state（代表共享资源）和一个FIFO线程等待队列（多线程争用资源被阻塞时会进入此队列）。队列中的每个节点是对线程的一个封装，包含线程基本信息，状态，等待的资源类型等。
- +------+ prev +-----+ +-----+
- head | | <---- | | <---- | | tail
- +------+ +-----+ +-----+ 下面简单看下获取资源的代码: public final void acquire(int arg) { // 首先尝试获取,不成功的话则将其加入到等待队列，再for循环获取 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }
// 从clh中选一个线程获取占用资源 final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { // 当节点的先驱是head的时候，就可以尝试获取占用资源了tryAcquire final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { // 如果获取到资源，则将当前节点设置为头节点head setHead(node); p.next = null; // help GC failed = false; return interrupted; } // 如果获取失败的话，判断是否可以休息，可以的话就进入waiting状态，直到被unpark() if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }

private Node addWaiter(Node mode) { // 封装当前线程和模式为新的节点,并将其加入到队列中 Node node = new Node(Thread.currentThread(), mode); // Try the fast path of enq; backup to full enq on failure Node pred = tail; if (pred != null) { node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } enq(node); return node; }

private Node enq(final Node node) { for (;;) { Node t = tail; if (t == null) { // tail为null，说明还没初始化，此时需进行初始化工作 if (compareAndSetHead(new Node())) tail = head; } else { // 否则的话，将当前线程节点作为tail节点加入到CLH中去 node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }

原文：https://blog.csdn.net/u010862794/article/details/72892300 https://www.cnblogs.com/waterystone/p/4920797.html

hz90 / java-base-knowledge

CAS AQS #5

：悲观锁适合写操作多的地方，先加锁保证写操作数据的正确性