Francis的博客

Java核心技术I第九章集合笔记

2019-09-17T14:05:16.000Z

一些乱七八糟的总结

队列通常的两种实现方式：循环数组和链表。
在Java 8 中迭代可迭代对象可以直接使用

1	iterator.forEachRemaining(element -> do something with element);

Iterator 接口的 remove 方法将会删除上次调用 next 方法时返回的元素，如果调用 remove 方法前没有调用 next 方法会抛出 IllegalStateException。
hashCode 方法的定义是要保证包含相同严肃的两个集会得到相同的散列码。
| 集合类型 | 描述|
| :-: | :-: |
| ArrayList | 一种可以动态增长和缩减的索引序列 |
| LinkedList | 一种可以在任何位置进行高效地插入和删除操作的有序序列 |
| ArrayDeque | 一种用循环数组实现的双端队列 |
| HashSet| 一种没有重复元素的无序集合 |
| TreeSet | 一种有序集合 |
| EnumSet | 一种包含枚举类型的集合 |
| LinkedHashSet | 一种可以记住元素插入次序的集合 |
| PriorityQueue | 优先队列 |
| HashMap | 键值对映射 |
| TreeMap | 一种键值有序排列的映射表 |
| EnumMap | 一种属于枚举类型的映射表 |
| LinkedHashMap | 一种可以记住键值项添加次序的映射表 |
| WeakHashMap | 一种其值无用武之地之后可以被垃圾回收器回收的映射表 |
| IdentityHashMap | 一种用 == 而不是 equals 比较键值的映射表
ListIterator 继承了 Iterator 其中定义了一些反向遍历等方法。并且通过get(n)方法可以返回链表指定位置元素(其中做了一些优化如果n大于size/2 那么从尾到头遍历)。
散列表通过链表数组实现，如果其中的桶被占满会出现散列冲突现象。
TreeSet 在 Java 8 之后使用红黑树进行实现。TreeSet 性能会比 HashSet慢一些。如果需要自定义比较器需要传入Comparator。
:: 为 Java 8之后的静态方法引用，注意是引用不是调用。
Collections 工具类中提供了很多方法比如排序，对集合的各种操作，返回不可更改集合，返回受查视图等。
toArray() 返回的是一个 Object[] 数组。

Java编程思想读书笔记三

2019-09-16T02:01:17.000Z

一些乱七八糟的总结

当 String 类型的对象进行修改操作的时候，编译器会自动引入 StringBuilder 类型，编译器会自动构造一个 StringBuilder 对象，用以构造最终的 String 。但是别指望编译器能有多智能，当String类型的对象进行循环更改操作的时候， StringBuilder 对象是在循环体中构造的，所以每次循环都会创建一个 StringBuilder 对象，而我们通过显示的使用 StringBuilder对象就可以避免这个问题。
如果想要打印对象的内存地址，需要在重写的 toString() 方法中使用 super.toString() 方法。
一旦某个类的 Class 对象被载入内存，它就用来创建这个类的所有对象。
类加载过程加载，链接，初始化。
使用嵌套类继承本身类并且实现 Null 接口(自己提前定义好的) 这样可以统一定义空对象而且避免空指针。
如果在集合内部使用数组的话，最好使用 Object[] 来存储而不是 T[] 。因为我们不太可能忘记这个数组的运行时类型，从而意外地引入缺陷(尽管大多数缺陷能再运行时被探测到)。
使用 System.arraycopy() 方法来赋值数组比for循环赋值来的更加高效便捷，对于对象的赋值，只是复制引用(浅拷贝)。
Arrays 类提供了重载之后的 equals() 方法数组相等的条件是数组元素个数相等，且对应位置上的元素也相等。
在已排序好的数组中可以使用 Arrays。binarySearch() 执行快速查找。

Java编程思想读书笔记二

2019-09-10T05:14:30.000Z

一些乱七八糟的总结

public访问权限：接口访问权限，任何都可以访问
protected访问权限：继承访问权限，任何子类可以访问，包内可以访问
默认访问权限：包访问权限，包内可以访问
private访问权限：私有访问权限，只有自己可以访问、
一个既是 static又是 final 的域值占据一段不能改变的存储空间
在java的早期实现中，如果将方法声明为 final 就是同意编译器针对对该方法的所有调用都转为内嵌调用，这样将消除方法调用的开销，可以提升性能，但是当方法很大，程序代码会很膨胀，因而可能看不到内嵌带来的任何性能提升。现在java版本，虚拟机能探测到这样的情况并优化去掉这些效率反而降低的额外的内嵌调用，*所以现在不需要使用final方法进行优化了。
在main方法调用前会先进性静态变量的初始化，如果有继承那么先加载父类的静态变量然后再加载派生类的静态变量。
多态是后期绑定，想想向上转型。
Java中除了 static 方法和 final 方法 ( private 属于 final 方法)，其他所有的方法都是后期绑定。所以这两个特殊的方法不具有多态性。
如果为一个类创建了dispose清理方法，然后我们继承了这个类，所以我们需要在导出类中覆盖dispose方法并且调用基类的dispose方法。
基类初始化 -> 基类构造 -> 导出类初始化 -> 导出类构造
销毁的顺序和初始化的顺序相反
用继承表达行为间的差异，并用字段表达状态上的变化
应尽量避免在不同接口中使用相同的方法名
当放入接口中的任何域都自动是 static 和 final 的
匿名类内部只能使用 final，匿名类没有命名构造器
将内部类声明为 static 它只能访问外围的 static 类型的变量方法等
可以使用嵌套类测试main、方法，这样可以避免需要编译所有代码。
可以使用内部类实现接口从而代替外部类同时实现多个接口
继承内部类的时候需要先进行外部类的实例化
内部类不会被覆盖不同类的内部类是完全两个不同的个体
TreeSet将元素存储在红黑树，而HashSet是散列函数，LinkedHashList因为查询速度的原因也使用了散列
异常链，即在捕捉到异常的时候再抛出异常。抛出异常的时候将上一个异常作为参数放入构造器中
如
1
2
3
4
5
try {
xxxx
} catch (IOException e) {
throw new ClassNotFoundException("xxxx", e);
}
即使try中有return，finally块中的语句还是会执行，但是在finally中抛出异常会直接生吞try中的异常。
在覆盖方法的时候，只能抛出基类方法的异常说明里列出的那些异常(可以是派生的异常)
注意构造器抛出异常导致finally清除出现异常，最好的是在最外围再嵌套一个try catch。
异常匹配会匹配最近的合适的异常。

Java编程思想读书笔记一

2019-08-29T06:31:49.000Z

前言

以前一直不敢读Java编程思想这本书，第一个原因是因为从别人口中听来这是一本进阶的书，我感觉自己的水平还达不到，第二个是因为这本书太厚了，且不说七八百页，每页密密麻麻的字就让人望而却步。现如今尝试一下拜读此书，希望自己能获取什么。

该系列博客仅为个人读书笔记，所以只是为了给自己看的，想着我的网站也没多少人会看，可能网站没备案导致搜索引擎搜不到，而最重要的是自己的文章只是泛泛而谈，精华确实很少，所以准备再花一段时间提升自己然后转战到类似掘金，简书等站点。

一些乱七八糟的总结

当使用父类作为多态的时候，应充分考虑抽象性
因为如果将子类 向上转型 为基类的话，那么子类很多拓展的功能是不能使用的。例如:

public void skin(Fruit fruit) {
    ...
    fruit.xxx;
}

这个时候应该考虑到，我们操作的是水果，我们中能调用水果中的方法而不能调用子类如苹果扩展出来的新方法。

Java要确定每种 基本类型 所占存储空间的大小
因为他们的大小不像其他语言一样随着硬件架构的变化而变化。
可以使用 BigInteger 或 BigDecimal 来实现高精度。
计算机的二进制会产生精度误差，使用这两个可以避免，但是效率会低。
Java 中没有作用域隐藏

{
    int x = 12;
    {
        int x = 96;  // 非法的
    }
}

上述代码在 java 中是非法的编译器会告诉你 x 已经定义，而 C++ 中可以，因为它会把外面的隐藏。

方法和参数列表合起来被称为 方法签名 它们唯一标识着某个方法。
main 函数中的 String[] args代表命令行参数，就比如JVM，Tomcat等启动命令附带的参数。
equals() 方法默认行为是比较引用
Java 允许我们把任何基本数据类型转换成别的基本数据类型，但布尔型除外
如果int 和 long相乘得到的结果会变为long，也就是会往 最大的数据类型 转换。
如果两个较大的基本数据类型相加如 int ，其结果可能会溢出。
在循环外可以定义标签来解决多层循环嵌套无法跳出的情况。

outer:
while(true) {
    ...
    inner:
    while(true) {
        if(...) {
            // break 会跳到标签，但是不会再次进入循环语句
            break outer;
        }
        if(...) {
            // continue 会调到标签并且会再次进入循环语句
            continue inner;
        }
    }
}

对象可能不被垃圾回收，垃圾回收不等于 C++ 中的析构。
不要使用finalize() 作为通用的清理方法。
之所以有finalize 是因为给对象分配内存的时候可能采用的不是new 而是使用c或c++的方式，而释放他们需要使用free类似函数，所以需要在finalize中用本地方法调用它。
new可以被看作 static 方法，比如

public class Initialization {
    // 这条语句会和static方法一样在构造对象之前执行
    Table table = new Table();
    // 但这个不行
    Table table1;
}

总结一下对象的创建过程:

即使没有显示地使用 static 关键字，构造器也是静态方法。因此当首次类型为Dog的对象的时候，或者Dog的静态方法/静态域首次被访问时，java解释器必须查找类路径，以定位Dog.class文件。
然后载入Dog.class(创建一个Class对象) 有关静态初始化的所有动作都会执行。因此，静态初始化只在Class对象首次加载的时候进行一次。
当用 new Dog() 创建爱你对象的时候，首先将在堆上为Dog对象分配足够的存储空间。
这块存储空间会被清零，这就自动将Dog对象中的所有基本类型数据都设置成了默认值，而引用被设置成了null。
执行所有出现于字段定义处的初始化动作。
执行构造器。

静态块代码只有在首次生成这个类的一个对象时，或者首次访问属于那个类的 静态数据成员时会执行，如果没有则不执行。
实例化子句会在构造器执行之前执行，而且每次都会执行。

public class Cat {
    {
        System.out.println("这是实例化子句");
    }
}

可变参数其实传进去的就是一个数组，尽量少使用可变参数，因为可变参数会产生冲突，可以给产生冲突的方法都加上可变参数，但不一定解决。
switch语句和enum搭配一起使用特别实用。

Java并发编程学习——Java并发编程之美学习笔记十

2019-08-22T04:00:50.000Z

Java并发保重线程同步器原理剖析

CountDownLatch 原理剖析

CountDownLatch 介绍

日常开发中可能我们可能遇到需要开启多个子线程去并行执行任务，并且 主线程需要等待所有子线程执行完毕后再进行汇总 的场景。我们可以使用 join() 方法(等待该子线程线程执行完毕)，但是join()不灵活而且很多场景可能使用不了，所以JDK中提供了 CountDownLatch 这个类。我们来看一下 CountDownLatch 的使用案例。

public class JoinCountDownLatch {

  private static volatile CountDownLatch countDownLatch = new CountDownLatch(2);

  public static void main(String[] args) throws InterruptedException {
    Thread thread1 = new Thread(new Runnable() {
      @Override
      public void run() {
        for (int i = 0; i < 1000; i++) {
          System.out.println("child thread1 running!");
        }
        countDownLatch.countDown();
        System.out.println("child thread1 over!");
      }
    });

    Thread thread2 = new Thread(new Runnable() {
      @Override
      public void run() {
        for (int i = 0; i < 1000; i++) {
          System.out.println("child thread2 running!");
        }
        countDownLatch.countDown();
        System.out.println("child thread2 over!");
      }
    });

    thread1.start();
    thread2.start();

    System.out.println("wait all child thread over");

    countDownLatch.await();

    System.out.println("all child thread over");
  }

}

运行结果:

我们可以看到 main 函数最后一条语句总是等待两个子线程运行结束才会运行。

当然我们还可以使用线程池的方式创建，以避免直接操作Thread。而且使用线程池来管理线程一般直接添加 Runnable 到线程池，这个时候我们就没有办法调用 join 方法了，所以说 CountDownLatch 比 join 更具有灵活性。

public class JoinCountDownLatch {

  private static volatile CountDownLatch countDownLatch = new CountDownLatch(2);

  public static void main(String[] args) throws InterruptedException {

    ExecutorService executorService = Executors.newFixedThreadPool(2);

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        for (int i = 0; i < 1000; i++) {
          System.out.println("child thread1 running!");
        }
        countDownLatch.countDown();
        System.out.println("child thread1 over!");
      }
    });

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        for (int i = 0; i < 1000; i++) {
          System.out.println("child thread2 running!");
        }
        countDownLatch.countDown();
        System.out.println("child thread2 over!");
      }
    });

    System.out.println("wait all child thread over");

    countDownLatch.await();

    System.out.println("all child thread over");
  }

}

CountDownLatch 实现原理探究

在学习 AQS 的时候提到过， AQS 是同步器的基本组成部分，而且其中 AQS 的 state 是用来表示 CountDownLatch 的计数器的。我们可以查看 CountDownLatch 的类图结构。

因为 Sync 是继承了 AQS 的，他实现了一些 AQS 的方法，所以可以说 CountDownLatch 是基于 AQS 实现的。

public CountDownLatch(int count) {
    if (count < 0) throw new IllegalArgumentException("count < 0");
    this.sync = new Sync(count);
}
// 设置 state
Sync(int count) {
    setState(count);
}

void await()
当线程调用 CountDownLatch 对象的 await() 方法后，当前线程会被阻塞(上面案例是主线程调用的await 所以主线程会被阻塞)，当所有线程调用了 CountDownLatch 的 countDown 方法后，即计数器的值为0的时候，调用 await 方法的线程会返回，或者当其他线程调用了当前被阻塞线程的 interrupt() 方法中断了饿当前线程，当前线程就会抛出 InterruptedException 异常返回。

public void await() throws InterruptedException {
    // 调用的是sync方法 其实就是调用的 AQS
    sync.acquireSharedInterruptibly(1);
}
public final void acquireSharedInterruptibly(int arg)
        throws InterruptedException {
    if (Thread.interrupted())
        throw new InterruptedException();、
    // 调用 tryAcquireShared 判断 这里AQS没有实现 调用的是实现类Sync的tryAcquireShared
    if (tryAcquireShared(arg) < 0)
        doAcquireSharedInterruptibly(arg);
}
// Sync的 tryAcquireShared
protected int tryAcquireShared(int acquires) {
    // 返回的state 不为0就返回 -1调用doAcquireSharedInterruptibly阻塞
    // 为0不阻塞
    return (getState() == 0) ? 1 : -1;
}
// 回顾一下 AQS 的阻塞 这是获取共享资源被阻塞 
private void doAcquireSharedInterruptibly(int arg)
    throws InterruptedException {
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        for (;;) {
            final Node p = node.predecessor();
            if (p == head) {
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    setHeadAndPropagate(node, r);
                    p.next = null; // help GC
                    failed = false;
                    return;
                }
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                throw new InterruptedException();
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

void countDown() 方法
线程调用该方法后计数器的值递减，如果递减后计数器为0则唤醒因为调用 await 方法而被阻塞的线程，否则什么都不做。

public void countDown() {
    sync.releaseShared(1);
}
// 这是 AQS 定义的
public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        doReleaseShared();
        return true;
    }
    return false;
}
// 这是Sync实现的
protected boolean tryReleaseShared(int releases) {
    // Decrement count; signal when transition to zero
    for (;;) {
        // 获取 state
        int c = getState();
        // 入过为0则false 意思就是什么都不做
        if (c == 0)
            return false;
        int nextc = c-1;
        if (compareAndSetState(c, nextc))
            // 如果CAS设置成功那么判断此时state是否为0 如果为0那么返回true
            // 返回true代表要对阻塞线程进行唤醒
            // 返回false代表什么都不做
            return nextc == 0;
    }
}
// AQS 中唤醒阻塞线程
private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;            // loop to recheck cases
                unparkSuccessor(h);
            }
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;                // loop on failed CAS
        }
        if (h == head)                   // loop if head changed
            break;
    }
}

CountDownLatch 小结

CountDownLatch 通过使用 AQS 实现，其中使用 AQS 的状态变量来存放计数器的值，当调用countDown方法的时候使state递减，调用await未得到满足的时候会调用线程会被放入 AQS 阻塞队列中等待。当其他线程调用 countDown方法并得到递减后的state为0的时候会调用 AQS 的 doReleaseShared 方法来激活由于调用 await() 方法而被阻塞的线程。

回环屏障 CyclicBarrier

对于 CountDownLatch 来说，线程同步后，等到计数器为0之后在调用 await 和 countDown 方法都会立即返回，也就是说 CountDownLatch 是一次性的。而 CyclicBarrier 会在所有子线程执行完毕后 重置 CyclicBarrier 的状态 。

CyclicBarrier 使用案例介绍

public class CyclicBarrierTest1 {

  // 这里构造方法里可以添加任务 这个任务会在所有调用await方法的线程全部到达
  // 屏障点(计数器为0)的时候调用
  // 并且等到这个任务执行完毕 被阻塞的线程会被唤醒继续执行
  private static CyclicBarrier cyclicBarrier = new CyclicBarrier(2,
      () -> System.out.println(Thread.currentThread() + "task1 merge result"));

  public static void main(String[] args) {
    ExecutorService executorService = Executors.newFixedThreadPool(2);

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "task-1");

        System.out.println(Thread.currentThread() + "enter in barrier");
        try {
          // 计数器会递减
          cyclicBarrier.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        } catch (BrokenBarrierException e) {
          e.printStackTrace();
        }
        System.out.println(Thread.currentThread() + "out barrier");
      }
    });

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "task-2");

        System.out.println(Thread.currentThread() + "enter in barrier");
        try {
          cyclicBarrier.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        } catch (BrokenBarrierException e) {
          e.printStackTrace();
        }
        // 被唤醒后继续执行
        System.out.println(Thread.currentThread() + "out barrier");
      }
    });

    executorService.shutdown();
  }

}

运行结果:

我们再来看一个重复使用的例子。这里我们没执行完一个步骤就汇总一次

public class CyclicBarrierTest2 {
  // 计数器初始化为2 并且定义了汇总任务
  private static CyclicBarrier cyclicBarrier = new CyclicBarrier(2,
      () -> System.out.println(Thread.currentThread() + "merge"));

  public static void main(String[] args) {
    ExecutorService executorService = Executors.newFixedThreadPool(2);

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "step1");
        try {
          cyclicBarrier.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        } catch (BrokenBarrierException e) {
          e.printStackTrace();
        }
        System.out.println(Thread.currentThread() + "step2");
        try {
          cyclicBarrier.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        } catch (BrokenBarrierException e) {
          e.printStackTrace();
        }
        System.out.println(Thread.currentThread() + "out barrier");
      }
    });

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "step1");
        try {
          cyclicBarrier.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        } catch (BrokenBarrierException e) {
          e.printStackTrace();
        }
        System.out.println(Thread.currentThread() + "step2");
        try {
          cyclicBarrier.await();
        } catch (InterruptedException e) {
          e.printStackTrace();
        } catch (BrokenBarrierException e) {
          e.printStackTrace();
        }
        System.out.println(Thread.currentThread() + "out barrier");
      }
    });

    executorService.shutdown();
  }

}

运行结果:

CyclicBarrier 实现原理探究

我们首先看一下 CyclicBarrier 的类图。

由此我们可以知道 CyclicBarrier 是通过 独占锁 来实现的。parties用来记录线程个数，这里表示多少个线程调用await方法后所有线程才会冲破屏障。count 一开始等于 parties，count计数器变为0之后会将parties的值重新赋值给count，以达到重复利用的功能。

public CyclicBarrier(int parties, Runnable barrierAction) {
    if (parties <= 0) throw new IllegalArgumentException();
    this.parties = parties;
    // 将parties 赋值给count
    this.count = parties;
    this.barrierCommand = barrierAction;
}
public CyclicBarrier(int parties) {
    this(parties, null);
}
// 独占锁
private final ReentrantLock lock = new ReentrantLock();
// 使用trip条件变量实现同步
private final Condition trip = lock.newCondition();
private final int parties;
private final Runnable barrierCommand;
private Generation generation = new Generation();
private int count;
// 里面的broken记录该屏障是否被打破
private static class Generation {
    boolean broken = false;
}

int await() 方法
当前线程调用该方法会被阻塞，知道满足下面条件之一才会返回:
1. parties个线程调用了该方法，即到达屏障点
2. 其他线程调用了当前线程的interrupt() 方法
3. 与当前屏障点关联的 broken 标志被设置为 true 会抛出 BrokenbarrierException 然后返回。

public int await() throws InterruptedException, BrokenBarrierException {
    try {
        return dowait(false, 0L);
    } catch (TimeoutException toe) {
        throw new Error(toe); // cannot happen
    }
}

int dowait() 方法

private int dowait(boolean timed, long nanos)
    throws InterruptedException, BrokenBarrierException,
           TimeoutException {
    // 获取锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 判断broken标志
        final Generation g = generation;
        if (g.broken)
            throw new BrokenBarrierException();
        // 是否被打断
        if (Thread.interrupted()) {
            // 被打断也要重置和唤醒
            breakBarrier();
            throw new InterruptedException();
        }
        // 将count递减
        int index = --count;
        // 如果执行后为0 那么执行屏障的任务
        if (index == 0) {  // tripped
            boolean ranAction = false;
            try {
                final Runnable command = barrierCommand;
                if (command != null)
                    command.run();
                ranAction = true;
                // 激活其他因调用await而被阻塞的线程 并重置cyclicBarrier
                nextGeneration();
                return 0;
            } finally {
                // 重置和唤醒
                if (!ranAction)
                    breakBarrier();
            }
        }
        // loop until tripped, broken, interrupted, or timed out
        for (;;) {
            try {
                // 没有设置超时时间
                if (!timed)
                    // 放入条件变量阻塞队列
                    trip.await();
                else if (nanos > 0L)
                    nanos = trip.awaitNanos(nanos);
            } catch (InterruptedException ie) {
                if (g == generation && ! g.broken) {
                    breakBarrier();
                    throw ie;
                } else {
                    // We're about to finish waiting even if we had not
                    // been interrupted, so this interrupt is deemed to
                    // "belong" to subsequent execution.
                    Thread.currentThread().interrupt();
                }
            }
            if (g.broken)
                throw new BrokenBarrierException();
            if (g != generation)
                return index;
            if (timed && nanos <= 0L) {
                breakBarrier();
                throw new TimeoutException();
            }
        }
    } finally {
        lock.unlock();
    }
}

// 唤醒阻塞队列并重置
private void nextGeneration() {
    // 唤醒条件队列的所有阻塞线程
    trip.signalAll();
    // 重置
    count = parties;
    generation = new Generation();
}

private void breakBarrier() {
    generation.broken = true;
    count = parties;
    trip.signalAll();
}

CyclicBarrier 小结

与 CountDownLatch 不同的是 CyclicBarrier 可以实现复用，并且特别适用分段任务有序执行的场景。CyclicBarrier适用独占锁来保证计数器的原子性更新，并使用条件队列来实现线程同步。

信号量 Semaphore 原理探究

Semaphore 也是 Java 中的一个同步器，和前面的 CountDownLatch 和 CyclicBarrier 不同的是 Semaphore内部的计数器是递增的，并且在初始化的时候可以指定一个初始值，但是 并不需要知道需要同步的线程个数，而是在需要同步的地方调用 acquire 方法时指定需要同步的线程个数 。

Semaphore 案例介绍

public class SemaphoreTest {

  // 生成 Semaphore 初始化计数器为0 因为是递增 所以只需要在需要
  // 的时候指定 递增到多少 不需要一开始指定需要同步的线程个数
  private static Semaphore semaphore = new Semaphore(0);

  public static void main(String[] args) throws InterruptedException {

    ExecutorService executorService = Executors.newFixedThreadPool(2);

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "over");
        semaphore.release();
      }
    });

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "over");
        semaphore.release();
      }
    });

    // 需要时指定acquire
    semaphore.acquire(2);

    System.out.println("merge");

    executorService.shutdown();

  }

}

运行结果:

我们再来看一下使用 Semaphore 实现复用。

public class SemaphoreTest2 {

  private static Semaphore semaphore = new Semaphore(0);

  public static void main(String[] args) throws InterruptedException {

    ExecutorService executorService = Executors.newFixedThreadPool(2);

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "taskA over");
        semaphore.release();
      }
    });

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "taskA over");
        semaphore.release();
      }
    });

    semaphore.acquire(2);

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "taskB over");
        semaphore.release();
      }
    });

    executorService.submit(new Runnable() {
      @Override
      public void run() {
        System.out.println(Thread.currentThread() + "taskB over");
        semaphore.release();
      }
    });

    semaphore.acquire(2);

    System.out.println("all task is over");


    executorService.shutdown();

  }

}

怎么能够复用呢？其实是因为主线程调用 acquire 方法返回后信号量会重新变成0。

Semaphore 实现原理探究

由类图可知，我们还是使用 AQS 实现的，并且还实现了获取信号量时是采用公平策略还是非公平策略。

// permits是初始化的计数器值
public Semaphore(int permits) {
    sync = new NonfairSync(permits);
}
public Semaphore(int permits, boolean fair) {
    sync = fair ? new FairSync(permits) : new NonfairSync(permits);
}

void acquire() 方法
当前线程调用该方法是 希望获取一个信号量资源。如果信号量个数大于0则当前信号量的计数会减一，然后该方法直接返回。否则如果当前信号量个数等于0，则当前线程会被放入 AQS 的阻塞队列。当其他线程调用该线程的 interrupt() 方法中断了当前线程，当前线程会抛出 InterruptedException 然后返回。

public void acquire() throws InterruptedException {
    sync.acquireSharedInterruptibly(1);
}
//  AQS 实现的
public final void acquireSharedInterruptibly(int arg)
        throws InterruptedException {
    // 如果打断 抛出异常
    if (Thread.interrupted())
        throw new InterruptedException();
    // 调用sync自己实现的tryAcquireShared 尝试获取共享资源
    // 如果小于0 阻塞当前调用线程
    if (tryAcquireShared(arg) < 0)
        doAcquireSharedInterruptibly(arg);
}
// 我们首先看非公平实现
protected int tryAcquireShared(int acquires) {
    return nonfairTryAcquireShared(acquires);
}
final int nonfairTryAcquireShared(int acquires) {
    // 无限循环
    for (;;) {
        // 获取状态值
        int available = getState();
        // 剩余量
        int remaining = available - acquires;
        // 如果剩余量小于0 那么返回剩余量 此时为负值 那么会直接调用doAcquireSharedInterruptibly
        // 不小于0 那么cas设置状态值 如果成功返回剩余量 设置不成功就一直循环
        // 如果返回大于0返回剩余值
        if (remaining < 0 ||
            compareAndSetState(available, remaining))
            return remaining;
    }
}
// 我们看一下 AQS 阻塞 放入阻塞队列里
private void doAcquireSharedInterruptibly(int arg)
    throws InterruptedException {
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        for (;;) {
            final Node p = node.predecessor();
            if (p == head) {
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    setHeadAndPropagate(node, r);
                    p.next = null; // help GC
                    failed = false;
                    return;
                }
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                throw new InterruptedException();
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

void acquire(int permits)

public void acquire(int permits) throws InterruptedException {
    if (permits < 0) throw new IllegalArgumentException();
    // 这里指定了个数
    sync.acquireSharedInterruptibly(permits);
}

void release()
该方法是把当前的 Semaphore 对象的信号量值增加1，如果当前线程又因为调用 acquire 方法被阻塞放入 AQS 阻塞队列中，则会 根据公平策略选择一个信号量个数能被满足的线程进行激活，激活的线程会尝试获取刚增加的信号量。

public void release() {
    sync.releaseShared(1);
}
// AQS
public final boolean releaseShared(int arg) {
    if (tryReleaseShared(arg)) {
        doReleaseShared();
        return true;
    }
    return false;
}
// Sync实现到的tryReleaseShared
protected final boolean tryReleaseShared(int releases) {
    // 无限循环
    for (;;) {
        // 获取当前信号量
        int current = getState();
        // 获取加上release的信号量
        int next = current + releases;
        // 如果相加后小于current 说明发生了整型溢出则抛出异常
        if (next < current) // overflow
            throw new Error("Maximum permit count exceeded");
        // 尝试CAS设置信号量 直到成功为止
        // 成功后会调用doReleaseShared 可选择AQS阻塞队列符合要求的线程进行激活
        if (compareAndSetState(current, next))
            return true;
    }
}
// AQS 进行激活
private void doReleaseShared() {
    for (;;) {
        Node h = head;
        if (h != null && h != tail) {
            int ws = h.waitStatus;
            if (ws == Node.SIGNAL) {
                if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                    continue;            // loop to recheck cases
                unparkSuccessor(h);
            }
            else if (ws == 0 &&
                     !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                continue;                // loop on failed CAS
        }
        if (h == head)                   // loop if head changed
            break;
    }
}

Semaphore 小结

Semaphore 内部使用了一个递增的计数器，这样就可以不在初始化的时候指定需要同步的线程个数了。它通过 AQS 实现，并且在获取信号量时有公平和非公平策略选择。

Java并发编程学习——Java并发编程之美学习笔记九

2019-08-20T05:52:43.000Z

Java并发包中 ScheduledThreadPoolExecutor 原理探究

介绍

上篇文章中有提到过 Executors ，这是一个工具类，他提供了很多静态方法返回不同的线程池实例。而其中的 newScheduledThreadPool 方法就提供了成成延迟线程池的实例。其中线程池队列是DelayWorkQueue 其和 DelayQueue 一样是一个延迟队列。

类图结构

ScheduledFutureTask 是具有返回值的任务，继承自FutureTask。FutureTask 的内部有一个变量 state 用来表示任务的状态。

private volatile int state;
// 初始
private static final int NEW          = 0;
// 执行中
private static final int COMPLETING   = 1;
// 正常运行结束
private static final int NORMAL       = 2;
// 运行中异常
private static final int EXCEPTIONAL  = 3;
// 任务被取消
private static final int CANCELLED    = 4;
// 任务正在被中断
private static final int INTERRUPTING = 5;
// 任务已经被中断
private static final int INTERRUPTED  = 6;

有可能的任务状态转换途径为:

NEW -> COMPLETING -> NORMAL

NEW -> COMPLETING -> EXCEPTIONAL

NEW -> CANCLLED

NEW -> INTERRUPTING -> INTERRUPTED

ScheduledFutureTask 内部还有一个变量 period 用来表示任务的类型。当 period 为0的时候说明当前任务是一次性的，period为负数的时候说明当前任务为 fixed-delay 固定延迟的定时可重复执行任务，period为整数说明当前任务为 fixed-rate 任务，是固定频率的定时可重复执行任务。

public static ScheduledExecutorService newScheduledThreadPool(intcorePoolSize) {
    return new ScheduledThreadPoolExecutor(corePoolSize);
}
public static ScheduledExecutorService newScheduledThreadPool(
        int corePoolSize, ThreadFactory threadFactory) {
    return new ScheduledThreadPoolExecutor(corePoolSize, threadFactory);
}
// 只有核心线程数目的构造函数 阻塞队列使用的是 DelayWorkQueue
public ScheduledThreadPoolExecutor(int corePoolSize) {
    super(corePoolSize, Integer.MAX_VALUE, 0, NANOSECONDS,
          new DelayedWorkQueue());
}

原理剖析

主要讲解三个重要函数

schedule(Callable< V > callable, long delay, TimeUnit unit)
scheduleWithFixedDelay(Runnable command, long initialDelay, long delay, TimeUnit unit)
scheduleAtFixedRate(Callable< V > callable, long delay, TimeUnit unit)

schedule(Callable< V > callable, long delay, TimeUnit unit)

该方法的作用是 提交一个延迟执行的任务 ，任务从提交时间算起延迟单位为 unit 的delay 时间后开始执行。提交的任务不是周期性任务，任务只会执行一次。

public ScheduledFuture schedule(Runnable command,
                                   long delay,
                                   TimeUnit unit) {
    // 判空
    if (command == null || unit == null)
        throw new NullPointerException();
    // 将任务转换为 RunnableScheduledFuture 类型
    RunnableScheduledFuture t = decorateTask(command,
        new ScheduledFutureTask(command, null,
                                      triggerTime(delay, unit)));
    // 添加任务到延迟队列
    // 因为延迟队列中的元素需要实现 元素实现是可比较的和继承Delayed并且拥有getDelay()方法
    // 而上面的 ScheduledFutureTask就实现了getDelay和compareTo方法
    // 其实最终这个t是ScheduledFutureTask类型的
    delayedExecute(t);
    return t;
}
// 我们来具体看一下 ScheduledFutureTask 相应的构造函数
ScheduledFutureTask(Runnable r, V result, long ns) {
    // 调用了父类的构造函数 父类是FutureTask
    super(r, result);
    this.time = ns;
    this.period = 0;
    this.sequenceNumber = sequencer.getAndIncrement();
}
// 这里可以想到Thread的一种创建方式
public FutureTask(Runnable runnable, V result) {
    // 将runnable转换为 callable
    this.callable = Executors.callable(runnable, result);
    // 设置当前任务状态为NEW
    this.state = NEW;       // ensure visibility of callable
}
// wtf？？
// 貌似什么都没做 返回一个 RunnableScheduledFuture 类型的task
// 注意我们前面调用的时候传入的是 ScheduledFutureTask 而 ScheduledFutureTask 
// 其实是实现了 RunnableScheduledFuture 的
protected  RunnableScheduledFuture decorateTask(
    Runnable runnable, RunnableScheduledFuture task) {
    return task;
}
private void delayedExecute(RunnableScheduledFuture task) {
    // 判断线程池是否是 SHUTDOWN 如果是则执行拒绝策略
    if (isShutdown())
        reject(task);
    else {
        // 获取BlockingQueue 然后添加任务到里面
        // DelayQueue就是实现了 BlockingQueue
        super.getQueue().add(task);
        // 再次获取状态
        // 如果是SHUTDOWN 且该任务可以运行给定当前运行状态和运行后关闭参数 那么移除task 然后取消任务
        if (isShutdown() &&
            !canRunInCurrentRunState(task.isPeriodic()) &&
            remove(task))
            task.cancel(false);
        // 不然保证至少有一个线程在处理任务
        else
            ensurePrestart();
    }
}
// 注意这里是执行任务了 就如上篇文章说到的 addWorker里面会执行任务
void ensurePrestart() {
    // 获取worker数量
    int wc = workerCountOf(ctl.get());
    // 如果小于核心 那么添加线程
    if (wc < corePoolSize)
        addWorker(null, true);
    // 小于0也添加线程
    else if (wc == 0)
        addWorker(null, false);
}

我们来看一下 ScheduledFutureTask 是如何执行任务的

public void run() {
    // 是否执行一次
    boolean periodic = isPeriodic();
    // 任务不可以运行给定当前运行状态和运行后关闭参数
    // 取消任务
    if (!canRunInCurrentRunState(periodic))
        cancel(false);
    // 只执行一次
    else if (!periodic)
        ScheduledFutureTask.super.run();
    // 定时执行
    else if (ScheduledFutureTask.super.runAndReset()) {
        // 设置time = time + period
        setNextRunTime();
        // 重新加入该任务到delay队列
        reExecutePeriodic(outerTask);
    }
}
// 父类的run FutureTask
public void run() {
    // 判断任务状态
    if (state != NEW ||
        !UNSAFE.compareAndSwapObject(this, runnerOffset,
                                     null, Thread.currentThread()))
        return;
    try {
        Callable c = callable;
        if (c != null && state == NEW) {
            V result;
            boolean ran;
            try {
                // 调用call方法并返回值
                result = c.call();
                ran = true;
            } catch (Throwable ex) {
                result = null;
                ran = false;
                // 如果任务失败 设置当前任务状态为 EXCEPTION
                setException(ex);
            }
            if (ran)
                // 最后设置任务状态为NORMAL
                // 所以这里只会执行一次 控制了任务状态
                set(result);
        }
    } finally {
        // 后续处理
        runner = null;
        // state must be re-read after nulling runner to prevent
        // leaked interrupts
        int s = state;
        if (s >= INTERRUPTING)
            handlePossibleCancellationInterrupt(s);
    }
}

总结

ScheduledThreadPoolExecutor 的实现原理是通过内部使用 DelayQueue 延迟队列存放具体任务，以达到延迟的效果。

Java并发编程学习——Java并发编程之美学习笔记八

2019-08-20T01:07:24.000Z

Java并发包中线程池 ThreadPoolExecutor 原理探究

介绍

线程池主要解决的两个问题: 一是当执行大量异步任务是线程池能提供较好的性能，使线程可复用而不需要再次new，二是提供一种资源限制和管理手段，比如可以限制线程的个数，动态新增线程等。

另外线程池也提供了许多可调参数和可扩展性接口，以满足不同情况的需要。我们可以使用更方便的 Executors 的工厂方法去创建线程池，比如其中的 newCachedThreadPool (线程池线程个数最多科大 Integet.MAX_VALUE 线程自动回收), newFixedThreadPool (固定大小)和 newSingleThreadExecutor (单个线程)。

类图介绍

ThreadPoolExecutor 继承了 AbstractExecutorService, 而 AbstractExecutorService 实现了 ExecutorService, ExecutorService 则实现了 Executor。 ThreadPoolExecutor 中有五个内部类，其中有四个是关于 policy 的，这是对于拒绝策略的实现(当线程池的状态不能再添加新任务执行的策略), 还有一个 Worker 类，他继承了 AQS 和实现了 Runnable，里面封装了firstTask记录着第一次执行的任务，thread保存的线程，这个线程的 Runnable 是 Worker 本身，当初始化的时候会将 this 传入 thread ，当 thread 启动的时候会调用 Worker 实现的 run() 方法，其中会调用runWorker(this),在这个方法里面就会取出 firstTask 然后调用它的 run 方法。

这里有一个 ctl 的原子变量，他和前面的读写锁有着异曲同工之妙，它通过一个变量记录着线程池状态和线程池线程个数，其中高三位表示线程池状态，其余表示线程池个数

// 初始化线程池状态为RUNNING 个数为0
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
// 线程池线程个数
private static final int COUNT_BITS = Integer.SIZE - 3;
// 容量
private static final int CAPACITY   = (1 << COUNT_BITS) - 1;
// runState is stored in the high-order bits
// RUNNING代表接受新任务并且处理阻塞队列的任务
private static final int RUNNING    = -1 << COUNT_BITS;
// SHUTTDOWN表示不接受新任务但会处理阻塞队列里的任务
private static final int SHUTDOWN   =  0 << COUNT_BITS;
// STOP表示拒绝新任务并且抛弃阻塞队列里的任务 同时中断正在执行的任务
private static final int STOP       =  1 << COUNT_BITS;
// 所有任务都执行完毕(包括阻塞队列里的) 将会调用terminated方法
private static final int TIDYING    =  2 << COUNT_BITS;
// 终止状态 terminated方法调用完成以后的状态
private static final int TERMINATED =  3 << COUNT_BITS;

线程池参数如下

corePoolSize: 线程池核心线程数。

workQueue: 用于保存等待执行的任务的阻塞队列,比如基于数组的有界ArrayBlockingQueue，基于链表的无界 LinkedBlockingQueue等等等。

maximunPooSize: 线程池最大线程数

threadFactory: 创建线程的工厂

RejectedExecutionHandler: 饱和拒绝策略前面提到过

keepAliveTime: 存活时间。如果当前线程池中的线程数量比核心线程数量多的时候，并且是闲置状态，则这些闲置的线程能存活的最大时间。

TimeUnit: 存活时间的时间单位。

mainLock: 独占锁， 用来控制新增 Worker 线程操作的原子性 。

termination: mainLock对应的条件队列，在线程调用 awaitTermination 时被阻塞的线程放入此队列。

Worker: 上文提到过是具体承载任务的对象，它继承了 AQS 实现了自己的简单不可重入独占锁，其中state = 0表示锁未被获取，为1表示锁已经被获取，为-1表示创建的默认状态，为了避免该线程在运行newWorker()方法前被中断。

源码分析

public void execute(Runnable command)
execute 方法的作用是提交任务 command 到线程池进行执行。

public void execute(Runnable command) {
    // 判空
    if (command == null)
        throw new NullPointerException();
    // 获取线程池状态和线程数量
    int c = ctl.get();
    // 如果线程数量小于核心数量
    if (workerCountOf(c) < corePoolSize) {
        // 调用addWorker增加
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
    // 如果是RUNNING状态则添加任务到阻塞队列
    if (isRunning(c) && workQueue.offer(command)) {
        // 再次获取
        int recheck = ctl.get();
        // 如果不是RUNNING则从队列中删除任务
        if (! isRunning(recheck) && remove(command))
            // 实施拒绝策略
            reject(command);
        // 如果线程数量为0增加线程
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);
    }
    // 如果队列满则新增线程 失败则实行拒绝策略
    else if (!addWorker(command, false))
        reject(command);
}

private boolean addWorker(Runnable firstTask, boolean core) {
    // 双重循环退出第一层循环的标志
    retry:
    for (;;) {
        // 获取到线程池状态和线程数量
        int c = ctl.get();
        // 线程池状态
        int rs = runStateOf(c);
        // 检查队列是否只在必要时为空
        // 将!展开得
        // rs >= SHUTDOWN && (rs != SHUTDOWN || firstTask != null || workQueue.isEmpty())
        // 以下几种情况会返回false
        // 当前线程池状态为STOP,TIDYING或者TERMINATED
        // 当前线程状态为SHUTDOWN 并且已经有了第一个任务
        // 当前线程状态为SHUTDOWN并且任务队列为空
        if (rs >= SHUTDOWN &&
            ! (rs == SHUTDOWN &&
               firstTask == null &&
               ! workQueue.isEmpty()))
            return false;
        for (;;) {
            // 获取线程数量
            int wc = workerCountOf(c);
            // 如果线程数量大于容量或者当前添加任务不是核心的时候当前线程数量大于最大数量
            // 如果是核心那么大于等于核心线程数量的时候返回false
            if (wc >= CAPACITY ||
                wc >= (core ? corePoolSize : maximumPoolSize))
                return false;
            // CAS增加线程数量
            if (compareAndIncrementWorkerCount(c))
                // 成功跳出整个循环
                break retry;
            c = ctl.get();  // Re-read ctl
            // 如果CAS失败查看线程池状态是否改变了
            // 变化则重新调到最外层循环再次获取
            if (runStateOf(c) != rs)
                continue retry;
            // 没有改变继续内层循环
        }
    }
    // 到这里说明CAS成功
    boolean workerStarted = false;
    boolean workerAdded = false;
    Worker w = null;
    try {
        // 创建worker 这时候会使用工厂来创建thread 但不一定能创建成功
        w = new Worker(firstTask);
        final Thread t = w.thread;
        // 如果thread不为空
        if (t != null) {
            // 获取到独占锁
            final ReentrantLock mainLock = this.mainLock;
            mainLock.lock();
            try {
                // 再次获取状态 避免前面操作的时候线程池状态改变了
                int rs = runStateOf(ctl.get());
                // 如果线程池状态为RUNNING 或者为 SHUTDOWN 并且第一个任务为空
                if (rs < SHUTDOWN ||
                    (rs == SHUTDOWN && firstTask == null)) {
                    // 提前检查线程是否已经开始运行 是则抛出线程状态异常
                    if (t.isAlive()) // precheck that t is startable
                        throw new IllegalThreadStateException();
                    // 新增到工作集中
                    workers.add(w);
                    int s = workers.size();
                    if (s > largestPoolSize)
                        largestPoolSize = s;
                    workerAdded = true;
                }
            } finally {
                mainLock.unlock();
            }
            if (workerAdded) {
                // 新增成功启动线程
                t.start();
                workerStarted = true;
            }
        }
    } finally {
        if (! workerStarted)
            addWorkerFailed(w);
    }
    return workerStarted;
}

工作线程worker的执行
当用户线程添加到线程池后，由worker来执行，先看下Worker的构造函数。

Worker(Runnable firstTask) {
    // 设置worker状态为-1 避免当前Worker在调用runWorker之前被中断
    // 可能其他线程调用了shutdownNow时 worker因为
    // state >= 0而导致此时被中断
    setState(-1); // inhibit interrupts until runWorker
    this.firstTask = firstTask;
    // 从工厂中获取线程 此线程会将this作为Runnable参数 因为Worker实现了饿Runnable接口
    this.thread = getThreadFactory().newThread(this);
}
// 我们再来看一下runWorker()
final void runWorker(Worker w) {
    // 获取当前线程
    Thread wt = Thread.currentThread();
    // 获取worker中的第一个任务
    Runnable task = w.firstTask;
    // 置为空
    w.firstTask = null;
    // 解锁 其中会把state变为 0
    w.unlock(); // allow interrupts
    boolean completedAbruptly = true;
    try {
        while (task != null || (task = getTask()) != null) {
            w.lock();
            // 如果池停止，则确保线程被中断；如果没有，则确保线程不中断
            if ((runStateAtLeast(ctl.get(), STOP) ||
                 (Thread.interrupted() &&
                  runStateAtLeast(ctl.get(), STOP))) &&
                !wt.isInterrupted())
                wt.interrupt();
            try {
                // 执行任务前做一些事情
                beforeExecute(wt, task);
                Throwable thrown = null;
                try {
                    // 执行
                    task.run();
                } catch (RuntimeException x) {
                    thrown = x; throw x;
                } catch (Error x) {
                    thrown = x; throw x;
                } catch (Throwable x) {
                    thrown = x; throw new Error(x);
                } finally {
                    // 执行完成做一些清理工作
                    afterExecute(task, thrown);
                }
            } finally {
                // 释放
                task = null;
                // 完成任务++
                w.completedTasks++;
                w.unlock();
            }
        }
        completedAbruptly = false;
    } finally {
        // 清理工作
        processWorkerExit(w, completedAbruptly);
    }
}

shutdown 操作
调用shutdown方法后线程池就不会接受新的任务了，但是工作队里里的任务还要执行的，该方法立即返回不等待队列任务完成再返回。

public void shutdown() {
    final ReentrantLock mainLock = this.mainLock;
    mainLock.lock();
    // 获取独占锁
    try {
        // 检查权限
        checkShutdownAccess();
        // 提前设置状态
        advanceRunState(SHUTDOWN);
        // 给所有空闲线程设置中断标志
        interruptIdleWorkers();
        onShutdown(); // hook for ScheduledThreadPoolExecutor
    } finally {
        mainLock.unlock();
    }
    tryTerminate();
}

private void interruptIdleWorkers() {
    interruptIdleWorkers(false);
}
private void interruptIdleWorkers(boolean onlyOne) {
    final ReentrantLock mainLock = this.mainLock;
    mainLock.lock();
    try {
        for (Worker w : workers) {
            Thread t = w.thread;
            // 如果线程没被中断 则尝试获取worker的锁
            if (!t.isInterrupted() && w.tryLock()) {
                try {
                    // 中断
                    t.interrupt();
                } catch (SecurityException ignore) {
                } finally {
                    w.unlock();
                }
            }
            // 如果打断一个 那么跳出循环 不然中断所有workers里的线程 (工作集合)
            if (onlyOne)
                break;
        }
    } finally {
        mainLock.unlock();
    }
}

总结

线程池巧妙地使用了Integer类型表示线程池状态和线程数量，在整个线程池中主要的操作其实就是execute，当执行的时候会判断线程池状态线程数量等因素。如果不满足那么会将任务(Runnable)加入阻塞队列，如果成功那么会加入工作集中并且执行。整个线程池能做到线程复用主要是吧Runnable和Thread分开来了，如果线程存活的时候且任务为空，当一个任务进来的时候该线程就能执行该任务。这样就减少了一些不必要的开销。当然还有很多线程池管理的细节，这里就不细说了。

Java并发编程学习——Java并发编程之美学习笔记七

2019-08-18T03:08:58.000Z

ConcurrentLinkedQueue 原理探究

ConcurrentLinkedQueue 类图结构

ConcurrentLinedQueue 内部使用单向链表的方式实现，其中有两个volatile类型的Node节点分别用来存放队列的首尾节点。

Node节点里面维护了一个使用 volatile 修饰的变量item，用来存放节点的值，next用来存放下一个节点，其内部使用 Unsafe 工具类提供的 CAS 算法来保证入队时操作链表的原子性。

从无参构造函数来看，默认头尾节点指向item为null的哨兵节点。ConcurrentLinkedQueue提供了一个传递Collection的有参构造函数，它会把Collection中的item封装成Node然后存放在队列中。

public ConcurrentLinkedQueue() {
    head = tail = new Node(null);
}
public ConcurrentLinkedQueue(Collection c) {
    Node h = null, t = null;
    for (E e : c) {
        checkNotNull(e);
        Node newNode = new Node(e);
        if (h == null)
            h = t = newNode;
        else {
            t.lazySetNext(newNode);
            t = newNode;
        }
    }
    if (h == null)
        h = t = new Node(null);
    head = h;
    tail = t;
}

ConcurrentLinkedQueue 原理介绍

ConcurrentLinkedQueue的原理很复杂，因为它是通过CAS实现来实现线程安全的并且是无锁的所以会考虑到很多种情况，这里只对代码和方法作用作简单的解析，如果想深入原理可以参考Java并发编程之美的第七章。

offer 操作
offer(E e) 是在队列末尾添加一个元素。 由于 ConcurrentLinkedQueue 是无界队列，所以该方法一直会返回true。另外使用的是 CAS 无阻塞算法，因此该方法不会阻塞挂起调用的线程。

public boolean offer(E e) {
    // 判断是否为null 如果为null抛出 NPE 异常
    checkNotNull(e);
    // 封装成Node
    final Node newNode = new Node(e);
    // 通过循环加入队列末尾
    for (Node t = tail, p = t;;) {
        Node q = p.next;
        if (q == null) {
            // 如果 p 的next为null 代表p为最后一个
            // 执行插入
            if (p.casNext(null, newNode)) {
                if (p != t)
                    casTail(t, newNode);  
                return true;
            }
        }
        // 多线程操作的时候由于 poll操作可能会把head变成自引用
        else if (p == q)
            // 需要重新设置head节点
            p = (t != (t = tail)) ? t : head;
        else
            // 不然重新寻找尾结点
            p = (p != t && t != (t = tail)) ? t : q;
    }
}

对于入队操作，offer会考虑到很多中情况，比如当进行到某些操作另一个线程调用了offer或者poll方法导致队列变化，正如上面代码中无限循环中的判断语句，其中的判断语句就是为了发生的多线程并发情况做准备，而整个offer(E e)方法最重要的就是使用CAS来控制某一时刻只有一个线程可以追加元素到队列末尾，而CAS失败的线程会通过无限循环判断队列的变化来再次进行CAS尝试，也就是说offer通过 无限循环不断进行 CAS 尝试方式来代替阻塞算法挂起调用线程 。相比阻塞算法，这就是 使用 CPU 资源换取则色所带来的的开销 。

poll 操作
poll() 是在队列头部获取并移除元素，如果队列为空则返回null。

public E poll() {
    // goto标记
    restartFromHead:
    for (;;) {
        for (Node h = head, p = h, q;;) {
            E item = p.item;
            // 当前节点有值则通过CAS设置为null
            if (item != null && p.casItem(item, null)) {
                // 更新头结点
                if (p != h)
                    updateHead(h, ((q = p.next) != null) ? q : p);
                return item;
            }
            // 当前队列为空则返回null
            else if ((q = p.next) == null) {
                updateHead(h, p);
                return null;
            }
            // 如果当前节点被自引用了 则跳出循环在进入循环寻找新的头结点
            else if (p == q)
                continue restartFromHead;
            else
                p = q;
        }
    }
}

可以看到的是，poll操作也考虑到了很多并发情况并做出处理，不得不说 Goug Lee 真的是一个天才，poll操作也是采用无限循环CAS代替阻塞算法的。

peek 操作
peek() 是获取头部的一个元素但是不移除。和poll差不多只不过这里不使用CAS来移除。

public E peek() {
    restartFromHead:
    for (;;) {
        for (Node h = head, p = h, q;;) {
            E item = p.item;
            if (item != null || (q = p.next) == null) {
                updateHead(h, p);
                return item;
            }
            else if (p == q)
                continue restartFromHead;
            else
                p = q;
        }
    }
}

size 操作
size() 是获取队列元素个数，采用的是遍历队列并自增count, 由于这里没有添加任何的锁所以在进行size操作的时候可能会有其他线程进行poll remove offer等操作，所以size并不是一个精确的值。

public int size() {
    int count = 0;
    for (Node p = first(); p != null; p = succ(p))
        if (p.item != null)
            // Collection.size() spec says to max out
            if (++count == Integer.MAX_VALUE)
                break;
    return count;
}

remove 操作
remove(Object object) 是删除指定元素,如果存在多个则删除第一个，如果队列为空则返回 false 。

public boolean remove(Object o) {
    if (o != null) {
        Node next, pred = null;
        for (Node p = first(); p != null; pred = p, p = next) {
            boolean removed = false;
            E item = p.item;
            if (item != null) {
                if (!o.equals(item)) {
                    next = succ(p);
                    continue;
                }
                removed = p.casItem(item, null);
            }
            next = succ(p);
            if (pred != null && next != null) // unlink
                pred.casNext(p, next);
            if (removed)
                return true;
        }
    }
    return false;
}

contains 操作
contains 是判断队列中是否含有指定元素，由于是遍历整个队列并且没有加锁，所以该操作也像size一样不是精确的。比如当调用该方法的时候该元素还在队列中，但是在遍历的时候其他线程调用了remove移除该元素，那么就会返回false。

public boolean contains(Object o) {
    if (o == null) return false;
    for (Node p = first(); p != null; p = succ(p)) {
        E item = p.item;
        if (item != null && o.equals(item))
            return true;
    }
    return false;
}

ConcurrentLinkedQueue 小结

ConcurrentLinkedQueue 底层是使用单向链表来保存队列元素的，每个元素包装成Node节点，队列是靠头尾节点来维护的，创建队列的时候头尾节点指向一个item为null的哨兵节点。第一次执行 peek 或者 first 操作的时候会把 head 指向第一个真正的队列元素。由于使用非阻塞 CAS 算法，在进行size contains操作的时候可能其他线程同时进行了offer remove等操作导致size contains不精确。

入队，出队都是操作使用 volatile 修饰的 tail， head节点。要保证在多线程情况下入队线程安全，只要保证两个Node操作的 可见性和原子性，由于volatile已经保证了可见性，所以只需要保证原子性就行。

而offer采用CAS来保证两个线程同时调用CAS进行设置的时候只有一个会成功，失败的线程会无限进行CAS尝试直到成功，这样就保证了两个Node节点操作的原子性，而poll方法也是类似的原理。

LinkedBlockingQueue 原理探究

LinkedBlockingQueue 类图结构

LinkedBlockingQueue 也是通过单向链表来实现的。last 和 head 是用来存放尾结点和头结点的，而原子变量 count 用来记录队列中的元素个数。另外还有两个 ReentrantLock 实例 takeLock 和 putLock，其中takeLock是线程进行获取元素的锁，putLock是线程进行添加元素的锁。

另外还有两个条件变量 notEmpty 和 notFull。它们内部都已一个条件队列，其实这就是一个 生产者——消费者模型 。

/** Lock held by take, poll, etc */
private final ReentrantLock takeLock = new ReentrantLock();
/** Wait queue for waiting takes */
private final Condition notEmpty = takeLock.newCondition();
/** Lock held by put, offer, etc */
private final ReentrantLock putLock = new ReentrantLock();
/** Wait queue for waiting puts */
private final Condition notFull = putLock.newCondition();

当线程在 LinkedBlockingQueue 实例上执行 take，poll等操作的时候需要获取takeLock，从而保证同一时刻只有一个线程能操作链表头结点。另外由于条件变量 notEmpty 内部的条件队列的维护使用的是takeLock的锁状态管理机制，所以在调用notEmpty的await和 signal方法前线程必须获得takeLock。当获得takeLock的线程调用了notEmpty的await方法时会被阻塞释放锁并放入相应的条件队列中，只有其他线程调用了notEmpty.signal方法的时候才能被唤醒重新竞争。

和上述一样，当线程在 LinkedBlockingQueue 实例上执行 put offer等操作的时候需要获取putLock，调用notFull的await和 signal 方法前线程也需要获取putLock等。二者相似，这里不再赘述。

// LinkedBlockingQueue 是一个有界队列 需要制定capacity
public LinkedBlockingQueue() {
    this(Integer.MAX_VALUE);
}

public LinkedBlockingQueue(int capacity) {
    if (capacity <= 0) throw new IllegalArgumentException();
    this.capacity = capacity;
    last = head = new Node(null);
}
public LinkedBlockingQueue(Collection c) {
    // 首先调用默认狗仔方法
    this(Integer.MAX_VALUE);
    // 因为要存入元素 所以要事先获取putLock
    final ReentrantLock putLock = this.putLock;
    putLock.lock(); // Never contended, but necessary for visibility
    try {
        int n = 0;
        for (E e : c) {
            if (e == null)
                throw new NullPointerException();
            if (n == capacity)
                throw new IllegalStateException("Queue full");
            enqueue(new Node(e));
            ++n;
        }
        // 设置大小
        count.set(n);
    } finally {
        putLock.unlock();
    }
}

LinkedBlockingQueue 原理介绍

offer 操作
向队列尾部插入一个元素，如果队列中有空闲则插入成功返回true，如果队列已满则丢弃当前元素返回false，如果元素为null 则抛出NPE，另外该方法是非阻塞的。

public boolean offer(E e) {
    // 判空
    if (e == null) throw new NullPointerException();
    // 获取count
    final AtomicInteger count = this.count;
    // 如果队列已满
    if (count.get() == capacity)
        return false;
    int c = -1;
    // 封装成Node
    Node node = new Node(e);
    // 获取putLock
    final ReentrantLock putLock = this.putLock;
    putLock.lock();
    try {
        // 为什么获取锁还要再次判断？
        // 因为有可能出现两个线程同时进入方法然后同时要获取锁
        // 比如线程A首先获取锁然后添加元素导致队列已满
        // 线程B原本以判断过队列是否已满 那时是未满 但这次进去就满了
        // 所以还要判断一次
        // 如果队列未满
        if (count.get() < capacity) {
            // 入队
            enqueue(node);
            // 增加
            c = count.getAndIncrement();
            // 如果队列还有空闲位置
            if (c + 1 < capacity)
                notFull.signal();
        }
    } finally {
        putLock.unlock();
    }
    // 这个时候count肯定是大于0的 因为前面做了自增
    // 这个时候则通知因为队列空而阻塞的线程
    if (c == 0)
        signalNotEmpty();
    return c >= 0;
}

put 操作
向队列尾部插入一个元素，如果队列有空闲则插入成功后返回，如果队列已满则阻塞当前线程，知道队列有空闲插入成功后返回。如果在阻塞过程中被其他线程设置了中断标志，则被阻塞线程会抛出InterruptException而返回。

public void put(E e) throws InterruptedException {
    // 判空
    if (e == null) throw new NullPointerException();
    int c = -1;
    // 封装Node
    Node node = new Node(e);
    // 获取锁
    final ReentrantLock putLock = this.putLock;
    final AtomicInteger count = this.count;
    // 这里调用了lockInterruptibly 这是能够响应中断的关键
    putLock.lockInterruptibly();
    try {
        // 放置虚假唤醒
        // 如果队列满
        while (count.get() == capacity) {
            notFull.await();
        }
        // 不然入队
        enqueue(node);
        c = count.getAndIncrement();
        // 队列还有空闲位置 通知因为队列满而被阻塞的线程
        if (c + 1 < capacity)
            notFull.signal();
    } finally {
        putLock.unlock();
    }
    // 此时count大于0 通知因为空而被阻塞的线程
    if (c == 0)
        signalNotEmpty();
}

poll 操作
从队列头移除一个元素，如果队列为空则返回null，该方法是非阻塞的。

public E poll() {
    final AtomicInteger count = this.count;
    // 判断队列是否为空
    if (count.get() == 0)
        return null;
    E x = null;
    int c = -1;
    // 获取takeLock
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lock();
    try {
        // 如果队列不为空则出队
        if (count.get() > 0) {
            x = dequeue();
            c = count.getAndDecrement();
            // 如果出队之后还有元素 通知因为队列空而被阻塞的队列
            if (c > 1)
                notEmpty.signal();
        }
    } finally {
        // 释放锁
        takeLock.unlock();
    }
    // 此时队列肯定有空闲位置
    if (c == capacity)
        signalNotFull();
    return x;
}

peek 操作
获取队列头元素但是不溢出，如果队列为空则返回null，该方法是非阻塞的。

public E peek() {
    if (count.get() == 0)
        return null;
    // 获取take锁
    final ReentrantLock takeLock = this.takeLock;
    takeLock.lock();
    try {
        Node first = head.next;
        if (first == null)
            return null;
        else
            return first.item;
    } finally {
        takeLock.unlock();
    }
}

take 操作
获取当前队列头部元素并且移除，如果队列为空则阻塞知道队列不为空然后返回元素，如果阻塞过程被其他线程设置了中断标志则抛出InterruptedException然后返回。和前面的 put 操作正好相反。

public E take() throws InterruptedException {
    E x;
    int c = -1;
    final AtomicInteger count = this.count;
    final ReentrantLock takeLock = this.takeLock;
    // 抛出InterruptedException的关键
    takeLock.lockInterruptibly();
    try {
        while (count.get() == 0) {
            notEmpty.await();
        }
        x = dequeue();
        c = count.getAndDecrement();
        if (c > 1)
            notEmpty.signal();
    } finally {
        takeLock.unlock();
    }
    if (c == capacity)
        signalNotFull();
    return x;
}

remove 操作
删除队列中指定元素有就删除并返回true，没有则返回false

public boolean remove(Object o) {
    // 为空则直接false
    if (o == null) return false;
    // 获取双重锁 因为这里要先获取然后移除
    fullyLock();
    try {
        // 遍历链表
        for (Node trail = head, p = trail.next;
             p != null;
             trail = p, p = p.next) {
            if (o.equals(p.item)) {
                // 移除
                unlink(p, trail);
                return true;
            }
        }
        return false;
    } finally {
        // 释放双重锁
        fullyUnlock();
    }
}
// 注意这里双重锁的获取和释放的顺序是颠倒的
void fullyLock() {
    putLock.lock();
    takeLock.lock();
}
    void fullyUnlock() {
    takeLock.unlock();
    putLock.unlock();
}

size 操作
获取当前队列元素个数

public int size() {
    // 直接返回count 因为count原子变量一直被维护着。
    return count.get();
}

LinkedBlockingQueue 小结

LinkedBlockingQueue 的内部通过单向链表来实现的，对头尾节点的操作分别使用了不同的独占锁，每个独占锁对应相应的Condition和条件队列，其实实现的是一个生产消费模型。

ArrayBlockingQueue 原理探究

ArrayBlockingQueue 类图结构

我们可以看出，ArrayBlockingQueue 内部有个数组items用来存放队列元素，putIndex 用来表示入队元素下标， takeIndex 用来表示出队元素下标， count 统计队列元素个数。这些变量都没有使用volatile 因为访问这些变量都是在锁块内，而锁已经保证了可见性。另外有一个独占锁lock用来保证出队入队的操作的原子性，这保证了同时只有一个线程能进行入队，出队操作，另外，notEmpty，notFull条件变量用来进行出队入队的同步。

// 有界队列需要传入容量大小
public ArrayBlockingQueue(int capacity) {
    // 默认非公平锁
    this(capacity, false);
}
public ArrayBlockingQueue(int capacity, boolean fair) {
    if (capacity <= 0)
        throw new IllegalArgumentException();
    this.items = new Object[capacity];
    // 同时生成锁和条件
    lock = new ReentrantLock(fair);
    notEmpty = lock.newCondition();
    notFull =  lock.newCondition();
}
public ArrayBlockingQueue(int capacity, boolean fair,
                          Collection c) {
    // 首先构建
    this(capacity, fair);
    // 获取锁然后将集合中的元素放入数组中
    final ReentrantLock lock = this.lock;
    lock.lock(); // Lock only for visibility, not mutual exclusion
    try {
        int i = 0;
        try {
            for (E e : c) {
                checkNotNull(e);
                items[i++] = e;
            }
        } catch (ArrayIndexOutOfBoundsException ex) {
            throw new IllegalArgumentException();
        }
        // 维持count
        count = i;
        // 如果个数已经到了容量那么设置putIndex为0
        putIndex = (i == capacity) ? 0 : i;
    } finally {
        // 释放锁
        lock.unlock();
    }
}

ArrayBlockingQueue 原理介绍

offer 操作
向队列尾部插入一个元素，如果队列有空闲空间则插入返回true，如果已满则丢弃并返回false，该方法是非阻塞的。作用和LinkedBlockingQueue中的offer方法基本一样。

public boolean offer(E e) {
    // 判空
    checkNotNull(e);
    // 获取独占锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 如果已满则丢弃返回false
        if (count == items.length)
            return false;
        else {
            // 入队
            enqueue(e);
            return true;
        }
    } finally {
        // 释放锁
        lock.unlock();
    }
}
private void enqueue(E x) {
    // assert lock.getHoldCount() == 1;
    // assert items[putIndex] == null;
    // 获取items数组
    final Object[] items = this.items;
    // 存入入队索引对应的空间
    items[putIndex] = x;
    // 如果队列满 则将putIndex置为0
    if (++putIndex == items.length)
        putIndex = 0;
    count++;
    // 通知因为队列空而被阻塞的线程
    notEmpty.signal();
}

put 操作
向队列尾部插入一个元素，如果队列有空闲则插入返回true，如果队列已满则阻塞当前线程知道队列有空闲插入后返回true，如果阻塞过程中被设置中断标志则抛出InterruptedException返回。和LinkedBlockingQueue的put也一样。

public void put(E e) throws InterruptedException {
    checkNotNull(e);
    // 获取锁
    final ReentrantLock lock = this.lock;
    // 关键
    lock.lockInterruptibly();
    try {
        // 防止虚假唤醒使用while
        while (count == items.length)
            // 如果满则阻塞
            notFull.await();
        enqueue(e);
    } finally {
        lock.unlock();
    }
}

poll 操作
从队列头获取并移除一个元素，如果队列为空则返回null，是非阻塞方法，和LinkedBlockingQueue 的poll方法一样。

public E poll() {
    final ReentrantLock lock = this.lock;
    // 获取独占锁
    lock.lock();
    try {
        // 如果不为空则出队 为空返回null
        return (count == 0) ? null : dequeue();
    } finally {
        lock.unlock();
    }
}
private E dequeue() {
    // assert lock.getHoldCount() == 1;
    // assert items[takeIndex] != null;
    final Object[] items = this.items;
    @SuppressWarnings("unchecked")
    E x = (E) items[takeIndex];
    // 将takeIndex索引下的元素置为null
    items[takeIndex] = null;
    // 如果出队索引是最后一个 那么重置为0
    if (++takeIndex == items.length)
        takeIndex = 0;
    // count减一
    count--;
    if (itrs != null)
        itrs.elementDequeued();
    // 通知因为队列满而被阻塞的线程
    notFull.signal();
    return x;
}

take 操作
获取当前队列头部元素移除，如果队列空则阻塞线程知道队列不为空被激活然后移除返回，如果阻塞过程被设置中断标志则抛出InterruptedException然后返回。和LinkedBlockingQueue的take一样。

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    // 关键
    lock.lockInterruptibly();
    try {
        while (count == 0)
            notEmpty.await();
        return dequeue();
    } finally {
        lock.unlock();
    }
}

peek 操作
获取头部元素但不从队列中移除它，如果队列为空则返回null，是非阻塞方法，和LinkedBlockingQueue的peek一样。

public E peek() {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 如果队列为空返回null
        return itemAt(takeIndex); // null when queue is empty
    } finally {
        lock.unlock();
    }
}

size 操作
计算当前队列元素个数

public int size() {
    final ReentrantLock lock = this.lock;
    // 在这里要加锁
    // 因为不加锁 如果其他线程调用offer poll等操作的时候会对count进行修改
    // 而这里count没有使用volatile修饰 不能保证可见性，所以需要在锁块里。
    // 这样返回的就是从主内存中的count，如果不加锁count调用此方法的时候会被放入缓存中！
    lock.lock();
    try {
        // 直接返回维护的count
        return count;
    } finally {
        lock.unlock();
    }
}

ArrayBlockingQueue 小结

ArrayBlockingQueue 通过使用全局独占锁实现了同时只能有一个线程操作队列(包括入队出队获取个数等操作)，由此可见，这个锁的粒度比较大，所以并发性能有一定影响。

PriorityBlockingQueue 原理探究

PriorityBlockingQueue 介绍

PriorityBlockingQueue 是带优先级的无界阻塞队列，每次出队都返回优先级最高或者最低的元素。其内部使用的是平衡二叉树堆实现的，所以遍历队列元素不保证有序，默认使用对象的compareTo方法提供比较规则，如果需要自定义可以自定义comparators。

PriorityBlockingQueue 类图结构

PriorityBlockingQueue 中有一个数组queue用来存放队列元素，size用来存放队列个数。 allocationSpinLock 是一个自旋锁，其使用 CAS 来保证同时只有一个线程能进行扩容操作，状态为0或者1,0表示当前没有线程进行扩容。

由于是一个优先级队列，所以有一个比较器 comparator 用来比较元素大小。lock独占锁用来控制同时只有一个线程能进行入队，出队操作。notEmpty条件用来实现take方法的阻塞，没有notFull是因为这是一个无界的优先级队列。

// 默认队列大小
private static final int DEFAULT_INITIAL_CAPACITY = 11;
// 默认构造
public PriorityBlockingQueue() {
    this(DEFAULT_INITIAL_CAPACITY, null);
}
// 指定大小
public PriorityBlockingQueue(int initialCapacity) {
    this(initialCapacity, null);
}
// 指定大小和比较器 如果默认则使用当前元素自身的比较器
public PriorityBlockingQueue(int initialCapacity,
                             Comparatorsuper E> comparator) {
    if (initialCapacity < 1)
        throw new IllegalArgumentException();
    this.lock = new ReentrantLock();
    this.notEmpty = lock.newCondition();
    this.comparator = comparator;
    this.queue = new Object[initialCapacity];
}

PriorityBlockingQueue 原理介绍

offer 操作
在队列中插入一个元素，由于是无界队列，所以一直返回true，这里没有在队头插入是因为这是优先级队列。

public boolean offer(E e) {
    // 判空
    if (e == null)
        throw new NullPointerException();
    // 获取独占锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    int n, cap;
    Object[] array;
    // 如果size 队列个数大于容量了则进行扩容操作
    while ((n = size) >= (cap = (array = queue).length))
        // 扩容
        tryGrow(array, cap);
    try {
        // 将队列比较器赋值过去
        Comparatorsuper E> cmp = comparator;
        // 如果为空
        if (cmp == null)
            siftUpComparable(n, e, array);
        else
            // 不为空
            siftUpUsingComparator(n, e, array, cmp);
        size = n + 1;
        // 入队成功后通知因为队伍空阻塞的线程
        notEmpty.signal();
    } finally {
        // 解锁
        lock.unlock();
    }
    return true;
}

我们需要看看如果size大于容量的时候优先队列是怎么进行扩容操作的。

private void tryGrow(Object[] array, int oldCap) {
    // 首先将进行offer时所抢占的锁释放
    // 因为扩容是一个费事的操作 这个时候释放出来让其他线程执行
    // 会提高并发能力
    lock.unlock(); // must release and then re-acquire main lock
    Object[] newArray = null;
    // 判断allocationSpinLock自旋锁标志 如果为0代表没有线程进行扩容
    // 如果为0使用CAS设置为1 控制只有当前线程能执行扩容
    if (allocationSpinLock == 0 &&
        UNSAFE.compareAndSwapInt(this, allocationSpinLockOffset,
                                 0, 1)) {
        // oldCapr如果小于64 则扩容为 oldCap + 2
        // 如果否则扩容50%，并且限制最大为MAX_ARRAY_SIZE
        try {
            int newCap = oldCap + ((oldCap < 64) ?
                                   (oldCap + 2) : // grow faster if small
                                   (oldCap >> 1));
            if (newCap - MAX_ARRAY_SIZE > 0) {    // possible overflow
                int minCap = oldCap + 1;
                if (minCap < 0 || minCap > MAX_ARRAY_SIZE)
                    throw new OutOfMemoryError();
                newCap = MAX_ARRAY_SIZE;
            }
            if (newCap > oldCap && queue == array)
                newArray = new Object[newCap];
        } finally {
            allocationSpinLock = 0;
        }
    }
    // 如果同时多个线程进行CAS CAS失败的线程会进入这里
    // newArray == null 代表第一个线程进去还没扩容完成 其余CAS失败的线程执行到这
    // yield尽量让出CPU资源 目的是让扩容的线程执行完扩容之后优先获得锁
    // 但这里的yield让出资源时不保证的 有可能扩容线程还未扩容完 yield就已经结束
    // 然后CAS失败的线程获取锁直接退出到offer方法
    if (newArray == null) // back off if another thread is allocating
        Thread.yield();
    lock.lock();
    // 如果扩容完毕并且获取到锁 复制当前queue里面的元素到newArray
    if (newArray != null && queue == array) {
        queue = newArray;
        System.arraycopy(array, 0, newArray, 0, oldCap);
    }
}

我们还需要看如何建堆的。

private static  void siftUpComparable(int k, T x, Object[] array) {
    Comparablesuper T> key = (Comparablesuper T>) x;
    // n为队列个数
    // 如果大于0代表队列中有元素 所以需要“排序”
    while (k > 0) {
        // 通过位移获取插入节点的父节点索引 相当于 (k - 1) / 2
        int parent = (k - 1) >>> 1;
        Object e = array[parent];
        // 如果key 大于 父节点 那么跳出循环
        // 不然交换并继续循环 由此可见这是一个最小堆
        if (key.compareTo((T) e) >= 0)
            break;
        array[k] = e;
        k = parent;
    }
    array[k] = key;
}

poll 操作
poll操作时获取队列内部堆树的根节点元素，如果队列为空返回null

public E poll() {
    // 获取锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        return dequeue();
    } finally {
        lock.unlock();
    }
}
private E dequeue() {
    // 获取最大索引
    int n = size - 1;
    // 队列为空返回null
    if (n < 0)
        return null;
    else {
        Object[] array = queue;
        // 获取队首元素
        E result = (E) array[0];
        // 获取队尾元素并赋值为null
        E x = (E) array[n];
        array[n] = null;
        Comparatorsuper E> cmp = comparator;
        // 将变量x插入数组下标为0的位置
        // 就是将堆底元素删除并插入堆顶然后重新排序
        if (cmp == null)
            siftDownComparable(0, x, array, n);
        else
            siftDownUsingComparator(0, x, array, n, cmp);
        size = n;
        return result;
    }
}

take 操作
获取队列内部堆树的根节点元素，如果队列为空则阻塞。

public E take() throws InterruptedException {
    final ReentrantLock lock = this.lock;
    // 调用对中断响应的lockInterruptibly
    lock.lockInterruptibly();
    E result;
    try {
        // 防止虚假唤醒
        while ( (result = dequeue()) == null)
            // 阻塞到条件队列中
            notEmpty.await();
    } finally {
        lock.unlock();
    }
    return result;
}

size 操作
计算队列元素个数。

public int size() {
    // 获取锁 由于是加锁的所以获取的size是精确的。
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        return size;
    } finally {
        lock.unlock();
    }
}

PriorityBlockingQueue 小结

PriorityBlockingQueue 内部使用 二叉树堆 来维护元素优先级，使用数组作为元素存储的数据结构，这个数组是可扩容的，当添加元素的时候需要重置顺序，通过 递归比较插入节点和父节点，当移除根元素的时候需要 删除末尾节点并将这个结点放入根节点的位置重新设置堆的顺序，这也是堆实现的通用方法。队列还维护一个comparator 用户可以自定义。总体通过一个独占锁来控制同时只有一个线程可以进行出队和入队操作，只是用了一个notEmpty的条件变量因为他是一个无界队列，执行put方法永远不会处于await和take方法是阻塞队列并且可以中断。

DelayQueue 原理探究

DelayQueue并发队列是一个 无界阻塞延迟队列 。队列中每个元素都有过期时间，当从队列中获取元素的时候只有过期元素才会出队，队列头元素就是最快要过期的元素。

Delay 类图结构

DelayQueue 内部使用 PriorityQueue 存放数据，使用 ReentrantLock 实现线程同步。另外队列里的元素要实现 Delayed 接口，由于每个元素都有过期时间所以要实现获知当前元素还有多少时间过期的接口，由于内部使用优先队列来实现，所以要实现元素之间相互比较的接口。

public interface Delayed extends Comparable<Delayed> {
    // 获取还剩多长时间
    long getDelay(TimeUnit unit);
}

其中 lock 是独占锁，available 是对应的条件变量， 其中 leader 变量的使用基于 Leader-Follower 模式的变体，用于尽量减少不必要线程的等待 。当一个线程调用队列的take方法变为leader线程后，它会调用条件变量 available 的awaitNanos(delay)等待delay时间，但是其他线程(follower线程)会调用 available 条件的await()进行无限等待。 leader线程延迟时间过期后会退出take方法，并通过调用 available.signal()方法唤醒一个follower线程被选举为leader线程。

DelayQueue 主要函数原理讲解

offer 操作
插入元素到队列，如果元素为null抛出NPE，否则由于无界一直返回true，插入元素要实现 Delayed 接口。

public boolean offer(E e) {
    // 获取独占锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 添加元素到优先级队列
        q.offer(e);
        // 获取头元素 如果是e
        // 那么设置leader为null
        if (q.peek() == e) {
            leader = null;
            // 通知某个等待线程
            available.signal();
        }
        return true;
    } finally {
        lock.unlock();
    }
}

take 操作
获取并移除队列里延迟过期的元素，如果队列里没有延迟过期的元素则等待

public E take() throws InterruptedException {
    // 获取锁
    final ReentrantLock lock = this.lock;
    // 可以被中断
    lock.lockInterruptibly();
    try {
        for (;;) {
            // 获取优先队列队首元素，如果为空则等待
            E first = q.peek();
            if (first == null)
                available.await();
            else {
                // 获取延迟时间
                long delay = first.getDelay(NANOSECONDS);
                // 如果小于0那么直接移除
                if (delay <= 0)
                    return q.poll();
                first = null; // don't retain ref while waiting
                // 查看leader是否为null 不为null说明其他线程也在执行take
                if (leader != null)
                    // 其他线程在执行则等待无限时间
                    available.await();
                else {
                    // 将当前线程设为leader
                    Thread thisThread = Thread.currentThread();
                    leader = thisThread;
                    try {
                        // 阻塞delay时间
                        // 这是会释放锁 其他线程能进行操作
                        available.awaitNanos(delay);
                    } finally {
                        // 最后将leader设置为null
                        if (leader == thisThread)
                            leader = null;
                    }
                }
            }
        }
    } finally {
        // 如果leader为null 且队头元素不为null 激活等待线程
        if (leader == null && q.peek() != null)
            available.signal();
        lock.unlock();
    }
}

poll 操作
获取并移除过期元素，没有过期元素返回null

public E poll() {
    if (size == 0)
        return null;
    int s = --size;
    modCount++;
    E result = (E) queue[0];
    E x = (E) queue[s];
    queue[s] = null;
    // 移除后调整堆顺序
    if (s != 0)
        siftDown(0, x);
    return result;
}

size 操作

public int size() {
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        return q.size();
    } finally {
        lock.unlock();
    }
}

DelayQueue 总结

DelayQueu内部使用了PriorityQueue存放数据，使用ReentrantLock实现线程同步，队列里的元素要实现Delayed接口，在出队时要判断元素是否过期了。

Java并发编程学习——Java并发编程之美学习笔记六

2019-08-16T07:25:17.000Z

LockSupport工具类

LockSupport是JDk rt.jar下面的一个工具类，主要作用是 挂起和唤醒线程 ，该工具类是 创建锁和其他同步类的基础 。

LockSupport与每个使用它的线程都会关联一个许可证，在默认情况下调用LockSupport的方法的线程是不持有许可证的。LockSupport是使用Unsafe类实现的。

LockSupport中的 void park() 方法

如果调用park()的线程已经拿到了与LockSupport关联的许可证，则调用LockSupport.park()时会马上返回，否则调用线程会被禁止参与线程的调度，也就是会被阻塞挂起。

如果其他线程调用 unpark(Thread thread) 并将该线程作为参数传入，此时因为调用 park()方法而被阻塞的线程会返回，另外如果其他线程调用了阻塞线程的Interrupt()方法，设置了中断标志或者线程被虚假唤醒，则阻塞线程也会返回，需要注意的是返回的时候不会抛出InterruptedException异常。

LockSupport中的 void unpark(Thread thread) 方法

当一个线程调用unpark方法，其中的参数线程如果没有持有与LockSupport类相关的许可证，那么会立即持有，如果线程在之前已经调用了park()方法而被阻塞，那么该线程会立即返回，如果没有调用park()方法，那么调用unpark()之后调用park()会直接返回(因为通过unpark()获取了许可证)

LockSupport中的 void parkNanos(long nanos) 方法

和park()方法差不多，只不过如果调用线程没有许可证，那么会被阻塞指定时间而返回。

LockSupport中的 park(Object blocker) 方法

public static void park(Object blocker) {
    // 获取当前线程
    Thread t = Thread.currentThread();
    // 设置Blocker
    setBlocker(t, blocker);
    // 挂起线程
    UNSAFE.park(false, 0L);
    // 线程被激活后清楚blocker
    setBlocker(t, null);
}

Thread类中有一个volatile Object parkBlocker用来存放传递的blocker，也就是把blocker变量存放到了线程本地。一般使用LockSupport.park(this),在打印线程堆栈的时候就可以获得相关阻塞类的信息了。

LockSupport中的 void parkNanos(Object blocker, long nanos)

比上面方法多一个超时时间。

LockSupport中的 void parkUntil(Object blocker, long deadline)

多设置一个最终时间

例子

public class FIFOMutex {

  private final AtomicBoolean locked = new AtomicBoolean(false);
  private final Queue waiters = new ConcurrentLinkedQueue<>();

  public void lock() {
    // 判断是否被中断
    boolean wasInterrupted = false;
    // 获取当前线程并加入队列中
    Thread current = Thread.currentThread();
    waiters.add(current);

    // 只有队首能获取锁
    while (waiters.peek() != current || locked.compareAndSet(false, true)) {
      LockSupport.park(this);
      if (Thread.interrupted()) {
        wasInterrupted = true;
      }
    }
    // 如果当前线程是队首并且没有其他线程抢占这个锁那么移除
    waiters.remove();
    // 如果刚刚被中断则相应中断
    if (wasInterrupted) {
      current.interrupt();
    }
  }

  public void unlock() {
    // 解锁的时候将布尔设置为false
    locked.set(false);
    // 激活等待中的队首线程
    LockSupport.unpark(waiters.peek());
  }

}

抽象同步队列 AQS 概述

AbstractQueuedSynchronizer 抽象同步队列简称 AQS。它是实现同步器的基本组件，并发包中锁的底层就是使用AQS实现的。

我们大致能看到AQS是一个FIFO的双向队列，其内部通过head和tail记录头尾节点，队列中元素类型为Node，其中Node中的thread变量用来存放AQS队列中的线程。Node节点内部的SHARED用来标记该线程是获取共享资源时被阻塞挂起进入AQS队列的，EXCLUSIVE用来标记该线程是获取独占资源时被阻塞挂起进入AQS队列的。wiatStatus用来记录当前线程的等待状态，可以为CANCELLED(线程被取消了)，SIGNAL(线程需要被唤醒)，CONDITION(线程在条件队列里等待)，PROPAGATE(释放共享资源的时候需要通知其他节点)；prev用来记录当前节点的前驱节点，next记录当前节点的后继节点。

在AQS中维持一个单一的状态信息state，可以通过getState，setState，compareAndSetState函数来操作，对于 ReentrantLock 的实现来说，state可以用来表示当前线程获取锁的可重入次数；对于读写锁 ReentrantReadWriteLock 来说，state的高16位表示读状态，低16位用来表示获取到写锁的线程的可重入次数。对于 semaphore 来说，state用来表示当前可用信号的个数，对于 CountDownlatch 来说，state用来表示计数器当前的值。

AQS有一个内部类 ConditionObject ，用来结合锁实现线程同步。ConditionObject可以直接访问AQS的内部变量，比如state状态值和AQS队列，ConditionObject是一个条件变量，每一个条件变量对应着一个条件队列(单向链表队列)。其用来存放调用条件变量的await()方法后被阻塞的线程，条件队列的头尾元素分别为firstWaiter和lastWaiter。

对于AQS来说， 线程同步的关键在于对state的操作 。独占方式下获取和释放资源使用的方法是acquire(int), void acquireInterruptibly(int), boolean release(int)。共享方式:acquireShared(int),acquireSharedInterruptibly(int),boolean releaseShared(int)方法。

共享方式指的是能有多个线程获取资源(只要符合要求)，独占指的是只能有一个线程获取资源。

独占方式获取和释放

// 在调用acquire获取的时候首先会调用tryAcquire来设置当前状态值
// 如果失败则会调用acquireQueued将其标志为EXCLUSIVE并放入AQS队列中
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
// 我们可以看到tryAcquire是需要子类去实现的
// 就比如ReentrantLock实现了对应的tryAcquire，使得state代表独占可重入
// 当state=0的时候代表没有线程占用，为大于等于1代表有线程占用并且state为可重入次数
protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}
// 在释放的时候首先会调用tryRelease()方法
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            // 唤醒头结点的后继节点
            unparkSuccessor(h);
        return true;
    }
    return false;
}
// 同样的tryRelease也需要子类实现去怎么设置state的值
protected boolean tryRelease(int arg) {
    throw new UnsupportedOperationException();
}

共享方式获取和释放

对于共享方式和独占方式基本差不多，只不过在获取资源失败的时候线程会被标记为SHARED并放入AQS队列。还需要注意的是对于acquire系列的方法有一些是带Interruptibly的，这些带有Interruptibly的需要对中断进行相应，即其他线程中断了次挂起线程后，这个线程需要抛出InterruptedException然后返回。

条件变量的支持

对于 synchronized 来说只能支持一个共享变量的notify或wait方法，而 AQS的锁能对应多个条件变量 ，和synchronized一样在调用条件变量的await和signal方法之前必须先获取条件变量对应的锁。

// 创建一个ReentrantLock独占可重入锁
ReentrantLock lock = new ReentrantLock();
// 通过锁创建一个条件变量
Condition codition = lock.newCondition();
// 获取锁
lock.lock();
try {
    begin wait...
    // 进入条件变量对应的阻塞队列
    condition.await();
    // 被唤醒后
    end wait...
} catch (Excepetion e) {
    e.printStackTrace();
} finally {
    // 解锁
    lock.unlock()
}

// 获取锁
lock.lock();
try {
    begin signal...
    // 唤醒条件变量对应的阻塞队列中的线程
    condition.signal();
    end signal...
} catch (Exception e) {
    e.printStackTrace();
} finally {
    // 解锁
    lock.unlock();
}

在其中有一个 lock.newCondition() 这个其实是new了一个在AQS中内部声明的一个ConditionObject对象，可以上去查看刚刚的类图。这个ConditionObject是AQS的一个内部类，每个条件变量维护了一个条件队列(我们可以看到ConditionObject中有firstWaiter lastWaiter等)用来存放调用相应condition的await()方法而被阻塞的线程。

我们来看condition的await方法

    public final void await() throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();
        // 创建节点并插入尾部
        Node node = addConditionWaiter();
        // 释放当前线程获取的锁
        // 将状态存入
        int savedState = fullyRelease(node);
        int interruptMode = 0;
        while (!isOnSyncQueue(node)) {
            // 调用lockSupport的park挂起线程
            LockSupport.park(this);
            if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                break;
        }
        if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
            interruptMode = REINTERRUPT;
        if (node.nextWaiter != null) // clean up if cancelled
            unlinkCancelledWaiters();
        if (interruptMode != 0)
            reportInterruptAfterWait(interruptMode);
    }
    // 插入条件队列尾部
    private Node addConditionWaiter() {
        Node t = lastWaiter;
        // If lastWaiter is cancelled, clean out.
        if (t != null && t.waitStatus != Node.CONDITION) {
            unlinkCancelledWaiters();
            t = lastWaiter;
        }
        Node node = new Node(Thread.currentThread(), Node.CONDITION);
        if (t == null)
            firstWaiter = node;
        else
            t.nextWaiter = node;
        lastWaiter = node;
        return node;
    }
    // 释放当前线程获取的锁
    final int fullyRelease(Node node) {
    boolean failed = true;
    try {
        int savedState = getState();
        if (release(savedState)) {
            failed = false;
            return savedState;
        } else {
            throw new IllegalMonitorStateException();
        }
    } finally {
        if (failed)
            node.waitStatus = Node.CANCELLED;
    }
}

我们再来看看signal方法

public final void signal() {
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    // 获取条件队列中的队头节点
    Node first = firstWaiter;
    if (first != null)
        doSignal(first);
}

private void doSignal(Node first) {
    do {
    if ( (firstWaiter = first.nextWaiter) == null)
            lastWaiter = null;
        first.nextWaiter = null;
    // 转移节点到AQS队列中
    } while (!transferForSignal(first) &&
             (first = firstWaiter) != null);
}
final boolean transferForSignal(Node node) {
    // 进入AQS队列中
    Node p = enq(node);
    int ws = p.waitStatus;
    if (ws > 0 || !compareAndSetWaitStatus(p, ws,Node.SIGNAL))
        // 唤醒线程
        LockSupport.unpark(node.thread);
    return true;
}

总结一下：当多个线程调用lock.lock()方法的时候，未竞争到锁的线程会被转换成一个NOde节点插入AQS队列中，如果获取到了锁的线程(因为某种条件不满足)调用了await()方法的时候，会被转换成Node节点并插入相应的Condition条件队列中并且释放锁，这个时候未获取到锁的线程(在AQS队列中)就可以重新竞争锁了，如果另外一个线程调用条件变量的signal()或者signalAll()方法，会把条件变量队列中的一个或全部Node移动到AQS阻塞队列里。

独占锁 ReentrantLock 的原理

类图结构

// 默认非公平锁
public ReentrantLock() {
    sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
}

其中 ReentrantLock 中有一个内部类Sync 这个类继承了AQS，并且扩展了公平锁(FairSync)和非公平锁(NonFairSync)

在Sync中AQS的state状态值表示 线程的可重入次数。

获取锁

void lock()

// 在ReentrantLock中的lock方法调用了sync的lock
public void lock() {
    sync.lock();
}
// 在Sync中是一各抽象方法是子类去实现
abstract void lock();
// 公平锁实现
final void lock() {
    acquire(1);
}
// 非公平锁实现
final void lock() {
    // CAS设置状态值
    // 如果成功则设置锁的持有者为当前线程
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    // 不然调用AQS的acquire
    else
        acquire(1);
}
// 再来回顾一下AQS的acquire方法
public final void acquire(int arg) {
    // 首先尝试调用tryAcquire
    // 不成功则加入AQS队列并设置标记为EXCLUSIVE(抢占独占资源而被阻塞的标志)
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
// 我们知道AQS并没有实现具体的tryAcquire方法 需要子类去实现
// 非公平锁实现的tryAcquire方法
protected final boolean tryAcquire(int acquires) {
    return nonfairTryAcquire(acquires);
}
// 非公平锁
final boolean nonfairTryAcquire(int acquires) {
    // 获取当前线程
    final Thread current = Thread.currentThread();
    // 获取当前状态值
    int c = getState();
    // 如果状态值为0 那么没有线程获取锁
    if (c == 0) {
        // 如果CAS设置成功
        if (compareAndSetState(0, acquires)) {
            // 设置锁持有者为当前线程
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    // 如果状态值不为0且当前线程为锁的持有者 那么将状态值加上参数acquires
    // 可重入锁的关键
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        // 数值校验
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}
// 公平锁的tryAcquire实现
protected final boolean tryAcquire(int acquires) {
    // 获取当前线程
    final Thread current = Thread.currentThread();
    // 获取装填值
    int c = getState();
    if (c == 0) {
        // 注意这里增加了一个hasQueuedPredecessors()校验
        // 根据字面意思就是判断是否有前驱节点
        // 如果没有那么执行和刚刚一样
        // 如果有且不是锁持有者就直接退出竞争
        if (!hasQueuedPredecessors() &&
            compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        int nextc = c + acquires;
        if (nextc < 0)
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;
}
// 公平锁实现的关键
public final boolean hasQueuedPredecessors() {
    Node t = tail; // Read fields in reverse initialization order
    Node h = head;
    Node s;
    // 验证当前队列是否只有一个元素或者当前线程是否是队列第一个元素（是否在哨兵节点的后面）
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

我们来回顾一下非公平机制和公平机制到底是怎么实现的。

比如这个时候有两个线程竞争ReentrantLock 线程A和线程B并且线程C已经获取了ReentrantLock，当线程A进入lock()方法然后进入acquire()方法再进入nonfairTryAcquire()方法(非公平策略)会因为这个锁已经被其他线程占有而被阻塞进入AQS队列，线程B也同时竞争锁，进入进入lock()方法然后进入acquire()方法再进入nonfairTryAcquire()方法(非公平策略)，而这个时候恰恰线程C释放了锁，那么线程B就会直接判断state值发现为0然后线程B就抢占了。我们可以发现，线程B是后来的但是先获得了锁，这就是非公平的体现。

而公平策略中会在抢占锁之前判断前面有没有线程在等待，如果有那么该线程直接放弃竞争。所以公平锁的资源浪费会比非公平高。

void lockInterruptibly() 方法
和lock()方法类似，但是它会对中断进行响应,就是当前线程在调用该方法的时候，其他线程如果调用了当前线程的interrupt()方法，该线程会抛出InterruptException异常然后返回。

释放锁

void unlock() 方法
尝试释放锁，如果当前线程持有锁则将AQS的state值减一，如果减下来为0那么该线程会释放锁，否则仅仅减一。如果当前线程没有持有锁而调用该方法会抛出IllegalMonitorStateException异常。

public void unlock() {
    sync.release(1);
}
public final boolean release(int arg) {
    // 首先尝试
    if (tryRelease(arg)) {
        // 如果释放成功那么唤醒下一个
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}
protected final boolean tryRelease(int releases) {
    // 将状态值减去参数
    int c = getState() - releases;
    // 如果没有获得锁的线程调用 抛出异常
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    // 设置free标志为false 后面要返回释放是否成功的
    boolean free = false;
    // 如果减去后为0那么就释放
    if (c == 0) {
        free = true;
        // 设置锁的持有者为空
        setExclusiveOwnerThread(null);
    }
    // 设置标志
    setState(c);
    // 返回释放是否成功
    return free;
}

读写锁 ReentrantReadWriteLock 原理

读写锁类图结构

读写锁内部维护了一个ReadLock和WriteLock，他们 依赖Sync来实现具体功能，而Sync继承AQS并且提供了公平和非公平锁的实现。

AQS中只维护了一个state变量，而读写锁中通过将state一分为二控制读状态和写状态。它巧妙的 将state的高16位表示读状态(也就是读锁的次数)，低16位表示写状态也就是写锁的可重入次数。

static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

/** Returns the number of shared holds represented in count  */
// 返回读锁线程数
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
/** Returns the number of exclusive holds represented in count  */
// 返回写锁可重入次数
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

其中 firstReader 用来获取第一个获取到读锁的线程， firstReaderHoldCount 则记录第一个获取到读锁的线程获取读锁的可重入次数， cachedHoldCounter 用来记录最后一个获取读锁的线程获取读锁的可重入次数。

// 内部类 里面维护了count和线程id
static final class HoldCounter {
    int count = 0;
    // Use id, not reference, to avoid garbage retention
    final long tid = getThreadId(Thread.currentThread());
}

readHolds 是 ThreadLocal变量，用来存放出去第一个获取读锁线程外的其他线程获取读锁的可重入次数， ThreadLocalHoldCounter 继承了ThreadLocal。

static final class ThreadLocalHoldCounter
    extends ThreadLocal<HoldCounter> {
    public HoldCounter initialValue() {
        return new HoldCounter();
    }
}

写锁的获取与释放

写锁通过WriteLock来实现。

void lock()

// WriteLock的lock()
public void lock() {
    sync.acquire(1);
}
// AQS的acquire
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}
// 读写锁的sync的tryAcquire
protected final boolean tryAcquire(int acquires) {
    /*
     * Walkthrough:
     * 1. If read count nonzero or write count nonzero
     *    and owner is a different thread, fail.
     * 2. If count would saturate, fail. (This can only
     *    happen if count is already nonzero.)
     * 3. Otherwise, this thread is eligible for lock if
     *    it is either a reentrant acquire or
     *    queue policy allows it. If so, update state
     *    and set owner.
     */
    // 获取当前线程
    Thread current = Thread.currentThread();
    // 获取当前状态 如果为0那么就代表没有线程获取读锁或者写锁
    int c = getState();
    // 获取写锁 即低16位
    int w = exclusiveCount(c);
    // 如果有线程获取写锁或者读锁
    if (c != 0) {
        // 因为肯定有线程获取写锁或者读锁 而且w=0代表没有线程获取写锁
        // 则肯定有线程获取读锁
        // 这里代表的是有线程获取读锁
        // 或者有线程获取读锁或者写锁且当前线程不是写锁拥有者
        // 的时候返回false
        if (w == 0 || current != getExclusiveOwnerThread())
            return false;
        // 如果有线程获取写锁并且是当前线程的
        if (w + exclusiveCount(acquires) > MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        // Reentrant acquire
        setState(c + acquires);
        return true;
    }
    // 如果当前没有线程获取读锁或者写锁 则尝试设置状态 不成功返回false 成功设置当前锁拥有者为当前线程并放回true
    if (writerShouldBlock() ||
        !compareAndSetState(c, c + acquires))
        return false;
    setExclusiveOwnerThread(current);
    return true;
}

我们来看一下writerShouldBlock的实现

// 非公平实现
static final class NonfairSync extends Sync {
    private static final long serialVersionUID = -8159625535654395037L;
    // 直接return false
    // 代表非公平直接竞争
    final boolean writerShouldBlock() {
        return false; // writers can always barge
    }
    final boolean readerShouldBlock() {
        return apparentlyFirstQueuedIsExclusive();
    }
}
// 公平实现
static final class FairSync extends Sync {
    private static final long serialVersionUID = -2274990926593161451L;
    final boolean writerShouldBlock() {
        return hasQueuedPredecessors();
    }
    final boolean readerShouldBlock() {
        return hasQueuedPredecessors();
    }
}
// 判断AQS中是否有前驱的
public final boolean hasQueuedPredecessors() {
    Node t = tail; // Read fields in reverse initialization order
    Node h = head;
    Node s;
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

boolean tryLock()

public boolean tryLock( ) {
    return sync.tryWriteLock();
}
// 和lock差不多 但是当当前已经有线程持有写锁或者读锁 直接返回false 不阻塞
// 如果CAS成功直接返回true
final boolean tryWriteLock() {
    Thread current = Thread.currentThread();
    int c = getState();
    if (c != 0) {
        int w = exclusiveCount(c);
        if (w == 0 || current != getExclusiveOwnerThread())
            return false;
        if (w == MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
    }
    if (!compareAndSetState(c, c + 1))
        return false;
    setExclusiveOwnerThread(current);
    return true;
}

void unlock()

public void unlock() {
    sync.release(1);
}
public final boolean release(int arg) {
    if (tryRelease(arg)) {
        // 成功·则通知唤醒下一个
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);
        return true;
    }
    return false;
}
protected final boolean tryRelease(int releases) {
    // 判断当前线程是否是该写锁的持有者
    if (!isHeldExclusively())
        throw new IllegalMonitorStateException();
    int nextc = getState() - releases;
    // 如果减到0那么释放
    boolean free = exclusiveCount(nextc) == 0;
    if (free)
        setExclusiveOwnerThread(null);
    setState(nextc);
    return free;
}

读锁的获取域释放

void lock()

public void lock() {
    sync.acquireShared(1);
}
// AQS的acquireShared
public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}
// AQS需要被实现的tryAcquireShared
protected int tryAcquireShared(int arg) {
    throw new UnsupportedOperationException();
}
// 读写锁实现的
protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    // 判断写锁是否被占用
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;
    // 如果当前线程是写锁拥有者也可以占用读锁
    // 记录当前读锁拥有数
    int r = sharedCount(c);
    // 判断readerShouldBlock
    // 队列里第一个是否在获取写锁 如果不是那么判断是否到达最大值 如果不是那么cas状态+1
    if (!readerShouldBlock() &&
        r < MAX_COUNT &&
        compareAndSetState(c, c + SHARED_UNIT)) {
        // 如果为0 那么设置firstReader
        if (r == 0) {
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) {
            // 如果当前线程已经是first了那么增加firstReaderHoldCount
            firstReaderHoldCount++;
        } else {
            // 不然放入cachedHoldCounter中
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                readHolds.set(rh);
            rh.count++;
        }
        return 1;
    }
    // 以上都不满足
    // 即写锁不被占用
    // 就自旋获取
    return fullTryAcquireShared(current);
}
static final class NonfairSync extends Sync {
    private static final long serialVersionUID = -8159625535654395037L;
    final boolean writerShouldBlock() {
        return false; // writers can always barge
    }
    // 非公平的readerShouldBlock实现
    final boolean readerShouldBlock() {
        return apparentlyFirstQueuedIsExclusive();
    }
}
final boolean apparentlyFirstQueuedIsExclusive() {
    Node h, s;
    // 如果队列里面存在一个元素 则判断第一个元素是否在尝试获取写锁
    return (h = head) != null &&
        (s = h.next)  != null &&
        !s.isShared()         &&
        s.thread != null;
}

void unlock()

public void unlock() {
    sync.releaseShared(1);
}
// 读写锁实现的tryReleaseShared
protected final boolean tryReleaseShared(int unused) {
    Thread current = Thread.currentThread();
    // 判断当前线程是不是第一个reader
    if (firstReader == current) {
        // assert firstReaderHoldCount > 0;
        // 如果是1 那么设置第一个读者为空
        if (firstReaderHoldCount == 1)
            firstReader = null;
        else
            // 不然 --
            firstReaderHoldCount--;
    } else {
        // 那么找其他线程 并通过线程id获取
        HoldCounter rh = cachedHoldCounter;
        if (rh == null || rh.tid != getThreadId(current))
            rh = readHolds.get();
        int count = rh.count;
        if (count <= 1) {
            readHolds.remove();
            if (count <= 0)
                throw unmatchedUnlockException();
        }
        --rh.count;
    }
    for (;;) {
        // 获取状态
        int c = getState();
        // 释放读锁对读取器没有影响，但如果读锁和写锁现在都是空闲的，它可能允许等待写入器继续进行
        int nextc = c - SHARED_UNIT;
        // 循环知道自己的读技术-1 CAS更新成功
        if (compareAndSetState(c, nextc))
            return nextc == 0;
    }
}

JDK8中新增的 StampedLock 探究

概述

StampedLock是JDK8中新增的锁，它提供了三种模式的读写锁

写锁。是一个独占锁而且是不可重入锁，请求该锁成功后会返回一个stamp参数来表示该锁的版本，当释放该锁的时候需要调用unlockWrite并传递获取锁是的stamp参数，并且它提供一个非阻塞的 tryWriteLock 方法。
悲观读锁。是一个共享锁，在没有线程占有写锁的情况下可以获取。如果有线程占用写锁，那么竞争该锁的线程会被阻塞(和读写锁的读锁很像但是他是不可重入锁) 这里悲观指 需要先将数据加锁，这是在读少写多的去情况的一种考虑。 该锁请求成功后也会返回一个stamp值，并且在调用unlockRead方法时需要传入获取该锁时的stamp来释放锁。并且它提供了一个非阻塞的 tryReadLock 方法。
乐观读锁。在操作数据之前没有通过CAS设置锁的装填，仅仅通过位运算测试，如果当前没有线程持有写锁，则简单返回一个非0的stamp版本信息。获取该stamp后再具体操作数据前还需要调用validate方法验证该stamp是否已经不可用，也就是看调用tryOptimisticRead返回stamp后当当前是否有其他线程持有了写锁，如果是则返回0，否则就可以通过该stamp版本的锁对数据进行操作，适用于读多写少的情况。
这三种锁还能在一定条件下相互转换。

最佳实践

我们可以巧妙的利用三种锁的转换和三种锁性能差异来设计一套最佳实践模板这也是官方推荐的。

// 读模板
final StampedLock sl = new StampedLock();
// 乐观读
long stamp = sl.tryOptimisticRead();
// 读⼊⽅法局部变量
......
// 校验 stamp
if (!sl.validate(stamp)){
 // 升级为悲观读锁
 stamp = sl.readLock();
 try {
 // 读⼊⽅法局部变量
 .....
 } finally {
 // 释放悲观读锁
 sl.unlockRead(stamp);
 }
}
// 使⽤⽅法局部变量执⾏业务操作
......

// 写模板
long stamp = sl.writeLock();
try {
 // 写共享变量
 ......
} finally {
 sl.unlockWrite(stamp);
}

Java并发编程学习——Java并发编程之美学习笔记五

2019-08-16T04:52:26.000Z

Java并发包中并发List介绍

并发包中的List只有 CopyOnWriteArrayList 。 CopyOnWriteArrayList是一个线程安全的List，对其的修改操作都是在底层的一个复制的数组上进行的，也就是使用了 写时复制 策略。

在CopyOnWriteArrayList中，每个对象里有一个array数组对象用来存放具体元素，ReentrantLock独占锁对象用来保证同时只有一个线程能对array进行修改。

如果让我们自己做一个写时复制的线程安全的List我们会怎么做？我们需要考虑什么？

何时初始化list，初始化list元素为多少个，list是有限大小吗？
如何保证线程安全？
如何保证使用迭代器遍历list时的数据一致性。

主要方法解析

构造方法

// 默认初始化个数0
public CopyOnWriteArrayList() {
    setArray(new Object[0]);
}

// 传入一个集合的时候，将集合复制到自身属性的array中
public CopyOnWriteArrayList(Collection c) {
    Object[] elements;
    if (c.getClass() == CopyOnWriteArrayList.class)
        elements = ((CopyOnWriteArrayList)c).getArray();
    else {
        elements = c.toArray();
        // c.toArray might (incorrectly) not return Object[] (see 6260652)
        if (elements.getClass() != Object[].class)
            elements = Arrays.copyOf(elements, elements.length, Object[].class);
    }
    setArray(elements);
}
// 传入为数组的时候直接复制
public CopyOnWriteArrayList(E[] toCopyIn) {
    setArray(Arrays.copyOf(toCopyIn, toCopyIn.length, Object[].class));
}

增加方法

public boolean add(E e) {
    // 获取独占锁并加锁
    final ReentrantLock lock = this.lock;
    lock.lock();
    try {
        // 获取自身array并且复制一个快照
        Object[] elements = getArray();
        int len = elements.length;
        Object[] newElements = Arrays.copyOf(elements, len + 1);
        // 在快照上进行操作
        newElements[len] = e;
        // 将新的快照赋值给array属性
        setArray(newElements);
        return true;
    } finally {
        // 最后解锁
        lock.unlock();
    }
}

获取指定位置的元素

final Object[] getArray() {
    return array;
}

@SuppressWarnings("unchecked")
private E get(Object[] a, int index) {
    return (E) a[index];
}

public E get(int index) {
    return get(getArray(), index);
}

获取操作并没有加锁，可能会产生 弱一致性问题 。比如当线程A执行get，线程B执行删除操作。线程A这里可以分为两个步骤 1. 获取当前array 2. 通过获取到的array根据索引获得指定元素。

假如这个时候当线程A执行完步骤1，然后线程B执行删除操作，我们假设线程A需要获得的是index为1的元素，此时线程B将原来array复制到新的array中然后对这个新array进行remove(1)的操作，之后把这个新的array重新赋值到对象中的array中，当这一系列操作完成后，线程A获取指定元素，而这个时候线程A是通过原来array获取的，所以它仍能获取到index为1的元素。

例如对于以下程序运行结果可能会是2或者3

public class CopyOnWriteArrayListTest {

  public static void main(String[] args) throws InterruptedException {
    CopyOnWriteArrayList copyOnWriteArrayList = new CopyOnWriteArrayList<>();
    copyOnWriteArrayList.add(1);
    copyOnWriteArrayList.add(2);
    copyOnWriteArrayList.add(3);
    copyOnWriteArrayList.add(4);
    Thread threadOne = new Thread(new Runnable() {
      @Override
      public void run() {
        copyOnWriteArrayList.remove(1);
      }
    });
    Thread threadTwo = new Thread(new Runnable() {
      @Override
      public void run() {
        System.out.println(copyOnWriteArrayList.get(1));
      }
    });
    threadOne.start();
    threadTwo.start();
    threadTwo.join();
    threadOne.join();
    System.out.println("结束");
  }
}

修改指定元素

public E set(int index, E element) {
    final ReentrantLock lock = this.lock;
    // 获取锁并加锁
    lock.lock();
    try {
        // 获取array
        Object[] elements = getArray();
        // 获取原来的指定元素
        E oldValue = get(elements, index);
        // 如果参数不和老值相同则进行更新
        if (oldValue != element) {
            int len = elements.length;
            // 复制array
            Object[] newElements = Arrays.copyOf(elements, len);
            // 在新的array中进行更新
            newElements[index] = element;
            // 重新设置array
            setArray(newElements);
        } else {
            // Not quite a no-op; ensures volatile write semantics
            // 确保volatile语义还是需要重新设置array
            // 因为对于volatile变量的写操作happens-before对volatile
            // 变量的读操作
            setArray(elements);
        }
        return oldValue;
    } finally {
        lock.unlock();
    }
}

删除指定元素

public E remove(int index) {
    final ReentrantLock lock = this.lock;
    // 获取锁并加锁
    lock.lock();
    try {
        // 进行快照的准备工作
        Object[] elements = getArray();
        int len = elements.length;
        E oldValue = get(elements, index);
        int numMoved = len - index - 1;
        // 如果删除的是最后一个
        if (numMoved == 0)
            // 直接移除最后一个的空间
            setArray(Arrays.copyOf(elements, len - 1));
        else {
            // 创建一个快照
            Object[] newElements = new Object[len - 1];
            System.arraycopy(elements, 0, newElements, 0, index);
            System.arraycopy(elements, index + 1, newElements, index,
                             numMoved);
            // 将array设置为快照
            setArray(newElements);
        }
        return oldValue;
    } finally {
        // 释放锁
        lock.unlock();
    }
}

弱一致性的迭代器

static final class COWIterator<E> implements ListIterator<E> {
    // 数组的快照
    private final Object[] snapshot;
    /** Index of element to be returned by subsequent call to next.  */
    private int cursor;

    private COWIterator(Object[] elements, int initialCursor) {
        cursor = initialCursor;
        snapshot = elements;
    }

    // 判断是否还有下一个元素
    public boolean hasNext() {
        return cursor < snapshot.length;
    }

    public boolean hasPrevious() {
        return cursor > 0;
    }

    // 遍历的方法
    @SuppressWarnings("unchecked")
    public E next() {
        if (! hasNext())
            throw new NoSuchElementException();
        return (E) snapshot[cursor++];
    }
    。。。。。
}

在snapshot中保存着当前array的快照,也就是说迭代器所操作的是array的一个快照，所以当其他线程对array进行更改的时候，迭代器是感知不到的，这又会产生弱一致性问题。

我们来看一下实例

public class CopyOnWriteArrayListTest {

  public static void main(String[] args) throws InterruptedException {
    CopyOnWriteArrayList copyOnWriteArrayList = new CopyOnWriteArrayList<>();
    copyOnWriteArrayList.add(1);
    copyOnWriteArrayList.add(2);
    copyOnWriteArrayList.add(3);
    copyOnWriteArrayList.add(4);
    copyOnWriteArrayList.add(5);

    Thread threadOne = new Thread(new Runnable() {
      @Override
      public void run() {
        copyOnWriteArrayList.set(1,123);
        copyOnWriteArrayList.remove(2);
        copyOnWriteArrayList.remove(3);
      }
    });
    // 保证iterator先获取
    Iterator integerIterator = copyOnWriteArrayList.iterator();

    threadOne.start();

    threadOne.join();

    while (integerIterator.hasNext()) {
      System.out.println(integerIterator.next());
    }

  }

}

我们可以看到运行结果是1 2 3 4 5

我们来看一下创建iterator的源码

public Iterator iterator() {
    return new COWIterator(getArray(), 0);
}
private COWIterator(Object[] elements, int initialCursor) {
    cursor = initialCursor;
    snapshot = elements;
}

其实跟上面讲到的获取和删除的弱一致性一样，因为修改和删除操作时对一个快照进行修改和删除的，并且最终把新的快照地址重新赋值给array，虽然此时的array指向的地址已经变了，但是原来迭代器中获取array的地址并没有改变，所以迭代器操作的还是原来的array，这就是写时复制产生的弱一致性问题。

Java并发编程学习——Java并发编程之美学习笔记四

2019-08-14T01:36:40.000Z

原子变量操作类

在JUC并发包中有很多原子变量类，比如AtomicInteger，AtomicLong和AtomicBoolean等。他们原理类似，这里讲解AtomicLong类，AtomicLong是原子性递增和递减类，其内部使用Unsafe实现。

public class AtomicLong extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 1927816293512124184L;

    // 获取unsafe实例
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    // 声明偏移量
    private static final long valueOffset;

    // 判断JVM是否支持long类型无锁CAS
    static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();

    private static native boolean VMSupportsCS8();

    static {
        try {
            // 获取value在Atomica中的偏移量
            valueOffset = unsafe.objectFieldOffset
                (AtomicLong.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    // 实际的变量值
    private volatile long value;

    // 初始化
    public AtomicLong(long initialValue) {
        value = initialValue;
    }

    public AtomicLong() {
    }

    // 获取
    public final long get() {
        return value;
    }

    // 设置
    public final void set(long newValue) {
        value = newValue;
    }

    public final void lazySet(long newValue) {
        unsafe.putOrderedLong(this, valueOffset, newValue);
    }

    // 获取并设置long值，返回原来long的值
    public final long getAndSet(long newValue) {
        return unsafe.getAndSetLong(this, valueOffset, newValue);
    }

    /**
     * 原子性设置值为被给予的更新值如果当前值与参数中到的expect期望值相等的话
     * Atomically sets the value to the given updated value
     * if the current value {@code ==} the expected value.
     *
     * @param expect the expected value
     * @param update the new value
     * @return {@code true} if successful. False return indicates that
     * the actual value was not equal to the expected value.
     */
    public final boolean compareAndSet(long expect, long update) {
        return unsafe.compareAndSwapLong(this, valueOffset, expect, update);
    }

    // 和上面方法一样 但是可能会失败而且不提供保证 一般很少代替上面的方法
    public final boolean weakCompareAndSet(long expect, long update) {
        return unsafe.compareAndSwapLong(this, valueOffset, expect, update);
    }

    // 原子性增加1
    public final long getAndIncrement() {
        return unsafe.getAndAddLong(this, valueOffset, 1L);
    }

    // 原子性减1
    public final long getAndDecrement() {
        return unsafe.getAndAddLong(this, valueOffset, -1L);
    }

    // 原子性增加指定的值
    public final long getAndAdd(long delta) {
        return unsafe.getAndAddLong(this, valueOffset, delta);
    }

    // 增加1且返回更新后的值
    public final long incrementAndGet() {
        return unsafe.getAndAddLong(this, valueOffset, 1L) + 1L;
    }

    // 原子性减1且返回更新后的值
    public final long decrementAndGet() {
        return unsafe.getAndAddLong(this, valueOffset, -1L) - 1L;
    }

    public final long addAndGet(long delta) {
        return unsafe.getAndAddLong(this, valueOffset, delta) + delta;
    }

    // 原子性更新循坏使用CAS 导致线程竞争
    public final long getAndUpdate(LongUnaryOperator updateFunction) {
        long prev, next;
        do {
            prev = get();
            next = updateFunction.applyAsLong(prev);
        } while (!compareAndSet(prev, next));
        return prev;
    }

    public final long updateAndGet(LongUnaryOperator updateFunction) {
        long prev, next;
        do {
            prev = get();
            next = updateFunction.applyAsLong(prev);
        } while (!compareAndSet(prev, next));
        return next;
    }

    // 传入函数 自定义算法
    public final long getAndAccumulate(long x,
                                       LongBinaryOperator accumulatorFunction) {
        long prev, next;
        do {
            prev = get();
            next = accumulatorFunction.applyAsLong(prev, x);
        } while (!compareAndSet(prev, next));
        return prev;
    }

    public final long accumulateAndGet(long x,
                                       LongBinaryOperator accumulatorFunction) {
        long prev, next;
        do {
            prev = get();
            next = accumulatorFunction.applyAsLong(prev, x);
        } while (!compareAndSet(prev, next));
        return next;
    }

    public String toString() {
        return Long.toString(get());
    }

    public int intValue() {
        return (int)get();
    }

    public long longValue() {
        return get();
    }

    public float floatValue() {
        return (float)get();
    }

    public double doubleValue() {
        return (double)get();
    }

}

在这里AtomicLong类可以直接获取Unsafe是因为它本身是在rt.jar下面的是通过Bootstrap类加载器加载的。

上面的原子操作类都是使用的CAS非阻塞算法，性能更好，但是在高并发的情况下Atomicxxx还存放着性能问题(会导致线程一直竞争CAS，导致大量资源浪费)，在JDK1.8之后提供了高并发下的LongAdder类。

JDK8新增的原子操作类LongAdder

在AtomicLong中，在高并发的情况下大量线程会同时竞争更新同一个原子变量，这样会导致大量线程失败通过无线循环不断进行自旋尝试CAS的操作，这回白白浪费CPU资源。

因为AtomicLong是多个线程竞争同一个原子变量，而LongAdder中则将原子变量和线程一一对应，比如设置一个Cell数组，其中的元素对应着每个线程(通过一定的算法实现)，然后最后获取值的时候将base(基础值)和cell数组中的元素值相加。

LongAdder维护了一个延迟初始化的原子性更新数组(默认情况为null)和一个基础值base。由于cell占用的内存相对较大所以是在需要的时候创建，即惰性加载。

因为cell是一个数组，数组中的元素内存地址是连续的，这就很容易导致伪共享的问题，在LongAdder中使用了@Contented注解来避免。

LongAdder代码分析

我们围绕着6个问题去分析源码

LongAdder的结构是怎样的答：继承了Striped64里面有一个base cell数组和cellBusy自旋操作标志
当前线程应该访问Cell数组里面的哪一个Cell元素答：获取当前线程的探针(作为每个线程对应哪一个cell的算法基础)，根据当前线程的随机数ThreadLocalRandomProbe和cell元素个数计算当前要访问的cell元素的下标，如果发现对应下标的元素为空则新增一个Cell元素到数组中并在之前将cellBusy设置为1防止其他线程竞争
如何初始化Cell数组答：懒加载但需要操作的时候进行初始化操作
Cell数组如何进行扩容答：当CPU个数大于cell元素进行扩容这时会多个CPU(线程)争抢一个cell元素产生冲突
线程访问分配的Cell元素后有冲突后应该如何处理答：进行扩容操作
如何保证线程操作被分配的Cell元素的原子性答：使用volatile保证内存可见性，使用cas操作保证操作原子性
我们可以看到LongAdder继承Striped64，而Striped64中维持着base，cellBusy，cell三个变量。
base是用来计算LongAdder的真实值的(base和cell元素相加),cellBusy是用来实现自旋锁的，状态值只有0和1，当创建Cell元素，扩容Cell数组或者初始化Cell数组的时候使用CAS操作该变量来保证同时只有一个线程可以进行其中之一的操作。
我们来看一下Cell的构造

@sun.misc.Contended static final class Cell {
    // 维持着一个long,保证内存可见性声明为volatile
    volatile long value;
    Cell(long x) { value = x; }
    // 进行cas操作，是更新时原子性的
    final boolean cas(long cmp, long val) {
        return UNSAFE.compareAndSwapLong(this, valueOffset, cmp, val);
    }

    // Unsafe mechanics
    private static final sun.misc.Unsafe UNSAFE;
    private static final long valueOffset;
    static {
        try {
            UNSAFE = sun.misc.Unsafe.getUnsafe();
            Class ak = Cell.class;
            valueOffset = UNSAFE.objectFieldOffset
                (ak.getDeclaredField("value"));
        } catch (Exception e) {
            throw new Error(e);
        }
    }
}

我们来看一下LongAdder源码

// 继承了Striped64
public class LongAdder extends Striped64 implements Serializable {
    private static final long serialVersionUID = 7249069246863182397L;

    public LongAdder() {
    }

    // 增加指定的值 主要操作
    public void add(long x) {
        Cell[] as; long b, v; int m; Cell a;
        // 如果数组为空且cas失败会进入
        // 或者数组不为空并且没有cas操作的时候进入
        if ((as = cells) != null || !casBase(b = base, b + x)) {
            boolean uncontended = true;
            // 当数组为空直接进入 这里就是数组为空且刚刚cas失败进入
            // 或者c数组不为空但再次cas失败则进入调用longAccumulate
            if (as == null || (m = as.length - 1) < 0 ||
                (a = as[getProbe() & m]) == null ||
                !(uncontended = a.cas(v = a.value, v + x)))
                longAccumulate(x, null, uncontended);
        }
    }

    // 增加1
    public void increment() {
        add(1L);
    }
    // 减少1
    public void decrement() {
        add(-1L);
    }

    // 计算所有的值即获取真正的value
    // 没有做加锁操作 所以并不是原子性的 会存在并发问题
    public long sum() {
        Cell[] as = cells; Cell a;
        long sum = base;
        if (as != null) {
            for (int i = 0; i < as.length; ++i) {
                if ((a = as[i]) != null)
                    sum += a.value;
            }
        }
        return sum;
    }

    // 重置所有元素为0
    public void reset() {
        Cell[] as = cells; Cell a;
        base = 0L;
        if (as != null) {
            for (int i = 0; i < as.length; ++i) {
                if ((a = as[i]) != null)
                    a.value = 0L;
            }
        }
    }

    // 计算并重置
    public long sumThenReset() {
        Cell[] as = cells; Cell a;
        long sum = base;
        base = 0L;
        if (as != null) {
            for (int i = 0; i < as.length; ++i) {
                if ((a = as[i]) != null) {
                    sum += a.value;
                    a.value = 0L;
                }
            }
        }
        return sum;
    }

    public String toString() {
        return Long.toString(sum());
    }

    public long longValue() {
        return sum();
    }

    public int intValue() {
        return (int)sum();
    }

    public float floatValue() {
        return (float)sum();
    }

    public double doubleValue() {
        return (double)sum();
    }


    private static class SerializationProxy implements Serializable {
        private static final long serialVersionUID = 7249069246863182397L;

        /**
         * The current value returned by sum().
         * @serial
         */
        private final long value;

        SerializationProxy(LongAdder a) {
            value = a.sum();
        }

        /**
         * Return a {@code LongAdder} object with initial state
         * held by this proxy.
         *
         * @return a {@code LongAdder} object with initial state
         * held by this proxy.
         */
        private Object readResolve() {
            LongAdder a = new LongAdder();
            a.base = value;
            return a;
        }
    }


    private Object writeReplace() {
        return new SerializationProxy(this);
    }


    private void readObject(java.io.ObjectInputStream s)
        throws java.io.InvalidObjectException {
        throw new java.io.InvalidObjectException("Proxy required");
    }

}

我们来看一下longAccumulate函数源码

    final void longAccumulate(long x, LongBinaryOperator fn,
                              boolean wasUncontended) {
        // 获取当前线程的探针(作为每个线程对应哪一个cell的算法基础)
        int h;
        if ((h = getProbe()) == 0) {
            ThreadLocalRandom.current(); // force initialization
            h = getProbe();
            wasUncontended = true;
        }
        boolean collide = false;                // True if last slot nonempty
        for (;;) {
            Cell[] as; Cell a; int n; long v;
            // 如果cell不为空
            if ((as = cells) != null && (n = as.length) > 0) {
                // 根据当前线程的随机数ThreadLocalRandomProbe和cell元素个数计算当前要访问的cell元素的下标，如果发现对应下标的元素为空则新增一个Cell元素到数组中并在之前将cellBusy设置为1防止其他线程竞争
                if ((a = as[(n - 1) & h]) == null) {
                    if (cellsBusy == 0) {       // Try to attach new Cell
                        Cell r = new Cell(x);   // Optimistically create
                        if (cellsBusy == 0 && casCellsBusy()) {
                            boolean created = false;
                            try {               // Recheck under lock
                                Cell[] rs; int m, j;
                                if ((rs = cells) != null &&
                                    (m = rs.length) > 0 &&
                                    rs[j = (m - 1) & h] == null) {
                                    rs[j] = r;
                                    created = true;
                                }
                            } finally {
                                cellsBusy = 0;
                            }
                            if (created)
                                break;
                            continue;           // Slot is now non-empty
                        }
                    }
                    collide = false;
                }
                // 如果cas已经知道失败则重置标志
                else if (!wasUncontended)       // CAS already known to fail
                    wasUncontended = true;      // Continue after rehash
                // 进行cas操作成功直接返回
                else if (a.cas(v = a.value, ((fn == null) ? v + x :
                                             fn.applyAsLong(v, x))))
                    break;
                // 如果cell元素个数大于CPU个数会产生冲突 冲突则进行扩容操作
                else if (n >= NCPU || cells != as)
                    collide = false;            // At max size or stale
                else if (!collide)
                    collide = true;
                else if (cellsBusy == 0 && casCellsBusy()) {
                    try {
                        if (cells == as) {      // Expand table unless stale
                            // 移位增加两倍
                            Cell[] rs = new Cell[n << 1];
                            for (int i = 0; i < n; ++i)
                                rs[i] = as[i];
                            cells = rs;
                        }
                    } finally {
                        // 扩容的时候进行cas操作避免其他线程进行扩容或者更新操作完成后设置cellBusy为0
                        cellsBusy = 0;
                    }
                    collide = false;
                    continue;                   // Retry with expanded table
                }
                h = advanceProbe(h);
            }
            // 如果为空则进行初始化
            else if (cellsBusy == 0 && cells == as && casCellsBusy()) {
                boolean init = false;
                try {                           // Initialize table
                    // 初始化
                    if (cells == as) {
                        Cell[] rs = new Cell[2];
                        rs[h & 1] = new Cell(x);
                        cells = rs;
                        init = true;
                    }
                } finally {
                    cellsBusy = 0;
                }
                if (init)
                    break;
            }
            else if (casBase(v = base, ((fn == null) ? v + x :
                                        fn.applyAsLong(v, x))))
                break;                          // Fall back on using base
        }
    }
```  

## LongAccumulator类原理探究

  LongAccumulator比LongAdder更加强大，原因在于LongAdder中只有累加操作，而LongAccumulator中是自定义函数来实现的。我们来看一下LongAccumulator的accumulate函数和LongAdder中的add方法的区别

```java
    public void accumulate(long x) {
        Cell[] as; long b, v, r; int m; Cell a;
        if ((as = cells) != null ||
            (r = function.applyAsLong(b = base, x)) != b && !casBase(b, r)) {
            boolean uncontended = true;
            if (as == null || (m = as.length - 1) < 0 ||
                (a = as[getProbe() & m]) == null ||
                !(uncontended =
                  (r = function.applyAsLong(v = a.value, x)) == v ||
                  a.cas(v, r)))
                // 这里传入了计算的值和一个函数
                longAccumulate(x, function, uncontended);
        }
    }

    public void add(long x) {
        Cell[] as; long b, v; int m; Cell a;
        if ((as = cells) != null || !casBase(b = base, b + x)) {
            boolean uncontended = true;
            if (as == null || (m = as.length - 1) < 0 ||
                (a = as[getProbe() & m]) == null ||
                !(uncontended = a.cas(v = a.value, v + x)))
                // 传入了值和一个null 我们可以猜测 传入null的时候给我们默认进行增加操作了
                longAccumulate(x, null, uncontended);
        }
    }

我们继续回顾一下刚刚上面的longAccumulate方法源码中最后一个else if

// 很明显 当fn为null的时候使用了v + x操作 不然调用该fn的applyAsLong
// 我们可以继续猜测这里面进行了自定义
 else if (casBase(v = base, ((fn == null) ? v + x :
    fn.applyAsLong(v, x))))
    break;

// 这就是一个函数接口
@FunctionalInterface
public interface LongBinaryOperator {

    /**
     * Applies this operator to the given operands.
     *
     * @param left the first operand
     * @param right the second operand
     * @return the operator result
     */
    long applyAsLong(long left, long right);
}

Java并发编程学习——Java并发编程之美读书笔记三

2019-08-13T06:51:26.000Z

Random类及其局限性

在JDK7之前包括现在Random都是使用比较广泛的随机数生成工具。在java.lang.Math中随机数生成也是使用的java.util.Random的实例。

下面是Random的一种常见的使用方式。

基本步骤就是生成一个Random实例，然后通过这个实例的方法去生成随机数字。

public class RandomTest {

  public static void main(String[] args) {
    Random random = new Random();
    for (int i = 0; i < 5; i++) {
      System.out.println(random.nextInt(10));
    }
  }

}

随机数的生成需要一个默认的种子，这个种子是一个long类型的数字。我们可以查看一下Random的源码。

// 无参构造函数其实是通过当前时间生成long类型的种子的
public Random() {
    // 调用的是有参构造函数
    this(seedUniquifier() ^ System.nanoTime());
}
public Random(long seed) {
    if (getClass() == Random.class)
        this.seed = new AtomicLong(initialScramble(seed));
    else {
        // subclass might have overriden setSeed
        this.seed = new AtomicLong();
        setSeed(seed);
    }
}

我们来看一下nextInt()方法的源码

// 无参nextInt方法调用了next方法
public int nextInt() {
    return next(32);
}

protected int next(int bits) {
    long oldseed, nextseed;
    // 获取当前的seed
    AtomicLong seed = this.seed;
    do {
        oldseed = seed.get();
        // 通过旧种子生成新种子
        nextseed = (oldseed * multiplier + addend) & mask;
        // CAS操作更新种子
    } while (!seed.compareAndSet(oldseed, nextseed));
    return (int)(nextseed >>> (48 - bits));
}

public int nextInt(int bound) {
    // 参数校验
    if (bound <= 0)
        throw new IllegalArgumentException(BadBound);
    // 还是调用的next方法
    // 后面通过计算控制范围
    int r = next(31);
    int m = bound - 1;
    if ((bound & m) == 0)  // i.e., bound is a power of 2
        r = (int)((bound * (long)r) >> 31);
    else {
        for (int u = r;
             u - (r = u % bound) + m < 0;
             u = next(31))
            ;
    }
    return r;
}

看了以上的代码，我们先不管种子是否是原子变量，如果多个线程去调用这个随机方法获得种子然后生成随机数，因为方法里新种子的生成依赖于旧种子，而旧种子是存放在共享变量里的，这里就会导致线程不安全问题，如果线程1生成一个种子，然后线程2和线程3同时调用该方法然后生成新种子，这个时候两个线程调用的旧种子是一样的，又因为旧种子变成新种子的算法是固定的，所以这两个线程得到的是同一个新种子，那么就意味着他们会生成同样的随机数。

而我们要注意的是在next方法里seed是被声明成AtomicLong类型的，它是原子变量，所以这样就可以解决线程安全的问题了(同一时刻只有一个线程能对这个原子变量进行操作)，后面原子变量的更新操作使用的是CAS操作，同一时刻只有一个线程能更新成功，这样就会 导致大量线程自旋重试 ，这样就极大地降低了并发性能。

ThreadLocalRandom

ThreadLocalRandom很好的解决了Random在高并发场景下的缺陷和不足。与ThreadLocal的原理一样ThreadLocalRandom使用的也是 线程封闭技术 。

使用方式和Random差不多。

public class RandomTest {
  public static void main(String[] args) {
    ThreadLocalRandom threadLocalRandom = ThreadLocalRandom.current();
    for (int i = 0; i < 10; i++) {
      System.out.println(threadLocalRandom.nextInt(10));
    }
  }
}

因为在Random中种子是共享变量，所以在多线程环境下会出现线程安全问题。而ThreadLocalRandom则是把种子变为线程本地变量。这样每个线程就会通过自己线程里的旧种子去更新种子。

ThreadLocalRandom源码分析

我们可以发现ThreadLocalRandom是继承了Random类的，但是需要注意的是ThreadLocalRandom并没有使用Random的seed变量，具体的变量存放在Thread中的ThreadLocalRandomSeed中(存放在线程中)。当调用ThreadLocalRandom的nextInt方法的时候，会获取当前线程的ThreadLocalRandomSeed变量并通过这个种子更新种子然后使用新种子来随机生成数字。

其中ThreadLocalRandom中的seeder和probeGenerator是两个原子性变量，在初始化调用线程的种子和探针的时候会用到他们，每个线程只会调用一次。

另外instance是ThreadLocalRandom的一个实例而且是static的，也就是说多个线程获取的是同一个实例，但是因为种子是存放在线程中的，所以不会产生安全问题。

Unsafe机制

private static final sun.misc.Unsafe UNSAFE;
private static final long SEED;
private static final long PROBE;
private static final long SECONDARY;
static {
    try {
        // 获取Unsafe实例
        UNSAFE = sun.misc.Unsafe.getUnsafe();
        Class tk = Thread.class;
        // 获取threadLocalRandomSeed，threadLocalRandomProbe，
        // threadLocalRandomSecondarySeed在Thread中的偏移量
        SEED = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("threadLocalRandomSeed"));
        PROBE = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("threadLocalRandomProbe"));
        SECONDARY = UNSAFE.objectFieldOffset
            (tk.getDeclaredField("threadLocalRandomSecondarySeed"));
    } catch (Exception e) {
        throw new Error(e);
    }
}

ThreadLocalRandom.current()方法

public static ThreadLocalRandom current() {
    // 判断是否为第一次调用，为0则为第一次调用，如果是做初始化操作
    if (UNSAFE.getInt(Thread.currentThread(), PROBE) == 0)
        localInit();
    // 返回统一的static实例
    return instance;
}
// 初始化当前线程的种子变量
static final void localInit() {
    // 初始化探针
    int p = probeGenerator.addAndGet(PROBE_INCREMENT);
    int probe = (p == 0) ? 1 : p; // skip 0
    // 初始化seed
    long seed = mix64(seeder.getAndAdd(SEEDER_INCREMENT));
    Thread t = Thread.currentThread();
    UNSAFE.putLong(t, SEED, seed);
    UNSAFE.putInt(t, PROBE, probe);
}

int nextInt(int bound)方法

public int nextInt(int bound) {
    // 参数校验
    if (bound <= 0)
        throw new IllegalArgumentException(BadBound);
    // 根据当前线程中的种子计算新种子
    int r = mix32(nextSeed());
    int m = bound - 1;
    if ((bound & m) == 0) // power of two
        r &= m;
    else { // reject over-represented candidates
        for (int u = r >>> 1;
             u + m - (r = u % bound) < 0;
             u = mix32(nextSeed()) >>> 1)
            ;
    }
    return r;
}

final long nextSeed() {
    Thread t; long r; // read and update per-thread seed
    // 更新种子
    UNSAFE.putLong(t = Thread.currentThread(), SEED,
    // 这里获取线程种子并进行 + GAMMA操作
                   r = UNSAFE.getLong(t, SEED) + GAMMA);
    return r;
}

总结

因为Random的种子生成随机数的方法，在Random中的种子是共享的所以多线程会出现并发问题，而Random中将种子声明成原子变量并且使用CAS更新会导致在多线程环境下多个线程去竞争资源，从而导致大量线程自旋，浪费资源和降低并发能力。

在ThreadLocalRandom中使用了线程封闭技术来解决这个问题，线程封闭即使线程本地化，将共享变量进行本地化，从而避免了线程安全问题和提高了并发能力。

Java并发编程学习——隐藏在并发包中的管程

2019-08-12T11:35:23.000Z

Java SDK并发包中的管程

在Java SDK并发包中通过Lock和Condition两个接口来实现管程，其中Lock用于解决互斥问题，Condition用来解决同步问题。

再造管程的理由

在Java 1.5之前synchronized是不如SDK中的Lock的，但1.6版本之后synchronized做了很多优化，将性能追了上来，所以为什么还要重新“造轮子”的原因不是性能问题，而是 死锁问题中的不可抢占条件 。

我们知道，synchronized是无法破坏不可抢占条件的，因为当线程申请不到锁的时候会直接阻塞。这个阻塞不会释放资源。

而让我们重新去设计一把互斥锁，其实有三种方法去解决。

能够响应中断。因为申请不到锁之后阻塞也不释放资源，所以我们希望阻塞线程能被通知中断唤醒并且释放曾经拥有过的资源。
支持超时。如果线程在一段时间内没有获取到锁，不是进入阻塞状态而是返回一个错误，这样线程也将右机会释放曾经获得的锁了。
非阻塞地获取锁。获取失败的时候不是进入阻塞状态而是直接返回，这样线程就有机会释放曾经持有的锁了。
而这三种方案，在Lock接口中都有对应的API
对应的lockInterruptibly()是支持中断的API，tryLock()是支持非阻塞获取锁的API，tryLock(long time,TimeUnit unit)是支持超时的API。

如何保证可见性

对于synchronized来说因为happends-before规则可以保证可见性，而在ReentrantLock实现类中内部持有了一个volatile变量state，并且在lock和unlock的时候读写state， 通过volatile的happens-before规则 。

锁的最佳实践

永远只在更新对象的变量时加锁
永远只在访问可变的成员变量的时候加锁
永远不再调用其他对象的方法的时候加锁(也许其他方法里面有线程sleep()或者IO操作，其他类也可能加锁会导致死锁)

思考

class Account {
  private int balance;
  private final Lock lock
          = new ReentrantLock();
  // 转账
  void transfer(Account tar, int amt){
    while (true) {
      if(this.lock.tryLock()) {
        try {
          if (tar.lock.tryLock()) {
            try {
              this.balance -= amt;
              tar.balance += amt;
            } finally {
              tar.lock.unlock();
            }
          }//if
        } finally {
          this.lock.unlock();
        }
      }//if
    }//while
  }//transfer
}

上面的代码不会产生死锁，但是可能会产生活锁。

Java并发编程学习——Java并发编程之美读书笔记二

2019-08-12T04:41:22.000Z

什么是多线程并发编程

并发：同一个时间段多个任务同时都在执行。

并行：多个任务在单位时间内同时执行。

也就是说并发使用cpu在短时间内切换进程造成了多个任务同时执行的假象。而在多线程编程实践中，线程的个数往往大于CPU个数，所以一般都称多线程并发编程而不是多线程并行编程(意味着一个核上存在多个线程，所以是并发)。

为什么要进行多线程并发编程

多核CPU时代打破了单核CPU对多线程效能的限制(频繁切换线程会带来额外开销)，多线程并发编程可以显著提高性能以应对海量数据和请求。

Java中的线程安全问题

多个线程去改变或读取(至少有一个去改变)一个共享资源会产生线程安全问题。

Java中共享变量的内存可见性问题

Java内存规定，将所有变量都存放在主内存， 当线程使用变量时，会把主内存里面的变量复制到自己的工作空间或者叫工作内存 。

而这个线程的工作内存又是怎样的呢？

上图是一个双核CPU系统架构，每个核都有自己的控制器和运算器，其中控制器包含一组寄存器和操作控制器，运算器执行算术逻辑运算。每个核都有自己的一级缓存，在有些架构里面还有一个所有CPU共享的二级缓存。 那么Java内存模型里面的工作内存，就对应着这里的L1或者L2或者CPU的寄存器 。

由于cache的存在会导致内存不可见，比如线程A和线程B要对一个共享变量x做增加的操作。

线程A首先去获取共享变量x的值，由于两级缓存都没有命中，那么线程A从主存中取出x的值为0并做增加操作，并且放入一级缓存和二级缓存，线程B也去获取共享变量x的值，首先一级缓存没有命中，二级缓存命中(刚刚线程A写入了二级共享缓存)，然后发现二级缓存中的值为1，然后进行增加操作并写入自己的一级缓存和二级缓存，主存。

这样看来没什么问题，但是如果线程A继续进行增加操作呢？线程A首先会去获取共享变量x的值，一级缓存命中！并且获取到了x的值为1，然后进行增加操作变为2，问题就出现了。

线程自己的工作内存(自己的缓存)会导致内存不可见性。

Java中的synchronized关键字

synchronized是Java提供的一种原子性内置锁，由于Java的线程和操作系统中的线程一一对应，所有当阻塞一个线程的时候，需要从用户态切换到内核态执行阻塞操作，这是一个很耗时的操作。而synchronized就会导致上下文切换。

synchronized的内存语意

synchronized代码块中的变量会 从线程的工作内存中清除 ，也就是说synchronized可以解决内存的不可见性。

Java中的volatile关键字

使用synchronized的方式可以解决内存不可见，volatile也可以。

当变量声明为volatile时，线程在写入变量时不会把值缓存在寄存器或者其他地方，而是把值刷新会主内存 。

volatile虽然解决了内存可见性问题，但是并不是原子操作，所以在多线程并发时也会出现异常。而一般在什么时候使用volatile关键字呢？

写入变量不依赖与变量的当前值(加一和赋值操作),因为如果依赖于当前值，那么获取——计算——写入这三步不是原子操作，而不保证volatile的原子性。
读写变量时没有加锁。加锁已经保证了内存可见性，所以没必要把变量再声明为volatile了。

java中的原子性操作

因为 线程切换是CPU指令级别的 ，而Java中的一条语句通常是由很多指令组成的，所以在多线程环境下线程切换会导致很多并发不安全的问题，而synchronized会保证同时只有一个线程执行。

Java中的CAS操作

CAS即Compare and Swap，是JDK提供的非阻塞原子性操作，它通过硬件保证了比较——更新操作的原子性。

ABA问题

当线程1使用CAS修改初始值为A的变量X，那么线程1会首先获取当前变量X的值，然后使用CAS操作尝试修改X的值为B，但是这个时候线程2使用CAS修改变量的值为B然后又通过CAS操作修改变脸的值为A，此时线程1执行CAS的时候X的值虽然是A，然是这个A已经不是线程1获取时的A了。

解决：ABA问题就是变量的状态发生了环形转换，可以提供给变量的状态值配置一个时间戳来避免ABA问题产生。

Unsafe类

Unsafe类提供了硬件级别的原子性操作，里面的方法都是native方法，他们使用JNI方式访问本地C++实现库。

当我们要使用Unsafe类的时候，在本身getUnsafe()方法中会判断当前类加载是否是Bootstrap类加载器，如果不是抛出异常，而我们启动main函数所在的类是使用AppClassLoader加载的，所以在main函数这里面加载Unsafe类的时候，根据委托机制，会委托给Bootstrap去加载Unsafe类。

如果不加以限制，我们可以直接通过Unsafe操作内存，这是不安全的，所以我们需要在rt.jar包下使用Unsafe类，我们也可以通过万能的反射来实现。

Java指令重排序

Java内存模型允许编译器和处理器对指令重排序以提高运行性能。而多线程的环境下指令重排序会导致一些并发问题，而如果使用volatile修饰变量可以避免一些重排序和内存可见性问题。

写volatile变量的时候，可以确保volatile变量写之前的操作不会被编译器重排序到volatile写之后。读volatile变量时，可以确保对volatile变量读之后的操作不会被编译器重排序到volatile读之前。

伪共享

什么是伪共享

为了解决内存和CPU之间的速度差异，CPU会添加一个或多个缓存存储器，而缓存在内部是 按行存储 的。因为局部性原理，当一个变量要存入缓存中其实是连带着周围的变量存入缓存的。所以存入Cache行的是内存而不是单个变量。

比如现在两个CPU，有两个变量x，y放入了缓存行，当线程1对CPU1的缓存行进行修改变量x的值的时候，因为缓存一致性协议，会导致CPU2对应的缓存行失效。所以线程2需要写入x或y的值的时候就要去二级缓存中查找。

为何出现伪共享

因为放入缓存行的是多个数据(是一个内存空间)。

如何避免伪共享

填充缓存行(创建一个对象封装相应的变量使对象空间和缓存行空间一样大)。

JDK8后使用sun.misc.Contended注解(会自动补齐缓存行)。

锁的概述

乐观锁和悲观锁

悲观锁：对数据被外界修改保持保守态度，认为数据很容易就被其他线程修改，在对数据处理之前先加锁。

乐观锁：认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而在进行数据提交更新的时候，才会正式对数据冲突与否进行检测。

公平锁与非公平锁

公平锁：先来先获得锁。

非公平：后来的也可以抢占锁。

在一般情况下使用非公平锁，公平锁会带来额外开销。

独占锁和共享锁

独占锁：只能一个线程拥有

共享锁：多个线程拥有，比如说ReadWriteLock读写锁允许一个资源被多个线程进行读操作。

可重入锁

可重入锁：已经获得了锁的资源再次申请该锁的时候不会被阻塞，synchronized就是一个可重入锁。

自旋锁

当前线程在获取锁的时候，如果发现锁已经被占用，它不马上阻塞自己，而是在不放弃CPU使用权的情况下，多次(默认情况下是10次)尝试获取。

Java并发编程学习——Java并发编程之美读书笔记一

2019-08-11T06:04:03.000Z

什么是线程

在操作系统中，进程是资源分配的基本单位，线程是资源调度的基本单位，因为真正占用CPU的是线程。

对于整个Java应用程序来说是一个进程，里面有很多线程。在操作系统中说，线程不独立拥有资源(进程是拥有资源的基本单位)，但是线程还是会拥有自己独立的一些资源的比如说程序计数器，栈等。

程序计数器：用来记录当前线程要执行的指令地址。我的理解是，第一为了确定线程要执行的后面的指令地址，第二是为了确保线程切换的时候，线程能记住它的执行状态(当前执行到哪了)，当下一次再次获得CPU资源的时候，线程能从它私有的程序计数器中获取指令地址继续执行。但是如果执行的是native方法，那么pc计数器记录的是undefined地址，只有执行Java代码的时候记录的才是下一条指令的地址。

栈：对于任何语言来说，线程是需要有栈的，这个栈中存放是就是栈帧。因为，对于CPU来说，是没有方法层面的，当高级语言进行方法调用的时候其实对于CPU来说还是执行相应地址中的指令，所以在高级语言中需要有一个方法调用栈，每执行一次方法调用的时候将参数，返回地址存入栈帧中并压入方法栈，等到被调用的方法执行完再出栈取出返回地址继续执行指令。而因为栈帧和方法同生死共命运，所以局部变量，参数等都是放入栈帧中的。

总结：线程中这个栈是方法调用栈，其中基本单位是栈帧，每次该线程进行方法调用的时候创建栈帧并压入方法调用栈，栈帧中有相应的方法参数，返回地址，和局部变量(Java中局部变量在栈中的原因)

堆：堆是进程中最大的一块内存，堆是被进程中的所有线程所共享的。堆中主要存放的是new操作创建的对象实例(Java对象在堆中)。

方法区：用来存放JVM加载的类，常量及静态变量等信息，也是所有线程共享的。

线程创建与运行

线程创建有三种方式

实现Runnable接口并重写run方法
继承Thread类并重写run方法
使用FutureTask创建
使用继承的好处是，获取当前线程直接使用this就可以了，但是Java不支持多继承，所以该类继承了Thread类之后不能再继承其他类了(降低了可扩展性)，而且继承Thread类即将任务代码和线程耦合了。
实现Runnable接口并重写run方法，最后将该实现接口实例作为参数传入Thread构造函数中，这种方法将任务代码和线程之间解耦，并且解决了多继承的问题。
而对于上面两种创建线程的方法来说，线程是没有返回值的，因为run方法是void方法。要使线程具有返回值可以通过FutureTask创建线程。
具体的步骤是：
创建一个类实现Callable接口并重写call()方法
将该类作为参数传入Thread构造方法并启动线程
最后通过FutureTask.get()等待任务执行完毕返回结果

线程等待与通知

wait()函数

它是Object中的一个方法，在并发编程中，它的调用者其实是共享变量，因为只有获得了synchronized隐式锁的线程才能使用wait方法，如果没有则会抛出IllegalMonitorStateException。

当线程调用这个wait方法的时候会被阻塞挂起，只有

其他线程调用了该共享变量的notify或者notifyAll(也就是说wait方法会释放当前共享变量的锁)
其他线程调用了该线程的interrupt()方法，该线程抛出InterruptedException异常并返回。
为了防范虚假唤醒，所以wait方法有它的编程范式

synchronized (obj) {
    while(条件不满足) {
        obj.wait();
    }
}

wait(long timeout)

增加wait时间限制，如果超出时间限制，不管上文提到的两个情况是否满足，该线程还是会因为超时而返回。

wait(long timeout, int nanos)

差不多，内部其实调用的是wait(long timeout)函数

notify()

会随机唤醒一个在该共享变量下调用wait()方法而阻塞的线程。

被唤醒的线程不能直接执行，还需要重新获得共享变量的锁，才能继续执行。

notifyAll()

通知所有在该共享变量下因为调用wait而阻塞的线程。

等待线程执行终止的join方法

join方法是Thread直接提供的无参且返回值为void的方法。

作用是等待线程执行完毕。

让线程睡眠的sleep()方法

会让线程暂时让出指定时间的执行权，也就是在这期间不参与CPU调度，但是线程持有的监视器资源(比如锁)是不会释放的。

让出CPU执行权的yield()方法

当一个线程调用这个方法的时候就是在暗示线程调度器当前线程请求让出自己的CPU使用，但是，线程调度器可以无条件忽略这个暗示。我们知道时间片轮转会让某个线程持有CPU资源一段时间，线程如果还没使用完这个时间就不想使用了，可以调用这个方法来告诉线程调度器可以进行下一轮的线程调度了。

线程中断

线程中断是线程之间的一种协作模式，通过设置中断标志不能直接终止线程的执行，而是 线程根据中断状态自己去处理 。

下面三个方法是关于线程中断的

void interrupt()方法中断线程，例如线程A执行时，线程B可以通过调用线程A的interrupt()方法来设置线程A的中断标志为true，并立即返回，注意：仅仅是设置中断标志，线程A并没有真正被中断。若线程A调用了wait(),join(),sleep()方法而被阻塞挂起的时候，线程B调用线程A的interrupt()方法会在 调用这些方法的地方抛出InterruptedException而返回(注意：这里是wait()这些方法，而不是interrupt()方法) 。
boolean isInterrupted()方法检测当前线程是否被中断，如果是返回true，否则false。
boolean interrupted()方法检测 当前线程 是否被中断，如果是返回true，否则false。并且它还会清除中断状态。它是Thread的静态方法，不管在哪调用返回的都是当前执行的线程的中断状态并清楚中断状态。
如果某个线程为了等待某些条件发生而阻塞(一般会调用sleep，wait或join函数)，比如这个线程调用了sleep(3000)函数去等待某种条件发生，但是在1秒的时候条件已经满足，这个时候可以调用该线程的interrupt()方法来 强制sleep()抛出InterruptedException而返回，线程恢复到激活状态。

理解线程上下文切换

正如一开始所讲的程序计数器，程序技术器中保存了相应的下一个执行指令地址，栈中保存了执行的一些信息。这些就是线程上下文切换所需要的资源。

线程上下文切换的时机

当前线程CPU时间使用完处于就绪状态。
当前线程被其他线程中断。

线程死锁

死锁的四个必要条件：1. 互斥，2. 请求并占有， 3. 不可剥夺， 4. 环路等待

避免：破坏一个必要条件。

守护线程与用户线程

Java中的线程分为两类：分别为daemon线程和user线程。JVM在启动时会调用main函数，main函数所在的线程是user线程，其实JVM在启动时还启动了好多daemon线程比如垃圾回收线程。

用户线程和守护线程的区别：当最后一个用户线程结束的时候JVM会退出，而守护线程的消亡不会影响到JVM的退出。

比如在main函数中启动一个无限循环的用户线程，当主线程执行完毕的时候JVM不会退出，但是如果把这个无限循环的线程改为守护线程，那么在主线程结束后JVM会自动退出。

如何设置守护线程？

1	deamonThread.setDaemon(true);

main线程运行结束后，JVM会自动启动一个叫做DestroyJavaVM的线程，该线程会等待所有 用户线程 结束后终止JVM进程。

而Tomcat的NIO实现NioEndPoint中会开启一组接受线程来接受用户的连接请求以及一组处理线程负责具体处理用户请求，这些线程线程被设置成了守护线程，即当tomcat收到shutdown命令之后并且没有其他用户线程存在的情况下，tomcat进程会马上消亡而不会等待处理线程处理完当前的请求。

ThreadLocal

线程本地化，可以将共享变量复制到线程本地存储空间。这是一种无锁的同步方式。

使用方式：创建ThreadLocal变量，在线程运行方法中设置刚刚的threadLocal变量实例。

实现原理

当ThreadLocal实例在线程执行的时候第一次调用set或者get方法的时候会在线程中创建相应的threadLocals(这个是一个ThreadLocalMap，一种定制化的HashMap，里面存放了许多线程本地化变量)，key为当前ThreadLocal实例的引用，值为自己设置的值。后面调用就直接会在线程的threadLocals这个Map中进行操作。

注意当本地变量不再使用的时候最好使用remove将其删除，避免内存溢出。还要注意的是ThreadLocal不支持继承，也就是说子线程不会拥有父线程的threadLocals变量。

但是可以使用InheritableThreadLocal类，可以追溯Thread创建的源码，Thread在创建的过程中会判断父线程的inheritableThreadLocals(上图的Thread中有这个私有变量)是否为空，如果不为空那么将其复制到子线程的inheritableThreadLocals中去。

Java并发编程学习——为什么局部变量是线程安全的

2019-08-10T09:32:30.000Z

局部变量不存在数据竞争

在并发编程领域里，没有共享就没有伤害。对于局部变量是不存在数据竞争的，为什么呢？

比如，下面代码里的 fibonacci() 这个方法，会根据传入的参数 n ，返回 1 到 n 的斐波那契数列，斐波那契数列类似这样： 1、1、2、3、5、8、13、21、34……第 1 项和第 2 项是 1，从第 3 项开始，每一项都等于前两项之和。在这个方法里面，有个局部变量：数组 r 用来保存数列的结果，每次计算完一项，都会更新数组 r 对应位置中的值。你可以思考这样一个问题，当多个线程调用 fibonacci() 这个方法的时候，数组 r 是否存在数据竞争（Data Race）呢？

// 返回斐波那契数列
int[] fibonacci(int n) {
  // 创建结果数组
  int[] r = new int[n];
  // 初始化第一、第二个数
  r[0] = r[1] = 1;  // ①
  // 计算 2..n
  for(int i = 2; i < n; i++) {
      r[i] = r[i-2] + r[i-1];
  }
  return r;
}

我们试想一下貌似多个线程同时执行fibonacci方法的时候对数组r的写入读取会发生数据竞争。

方法是如何被执行的

对于CPU来说是没有方法这一层面的，对于它来说任何操作都是一条条指令，那么CPU如果进行一个方法调用总要进行返回到调用方法的代码片段(地址)去执行，这个CPU是怎么做到的呢？

答案就是栈，在我的关于栈的文章中提到过方法栈，CPU就是通过栈来实现返回到原来调用方法的地址的。

在线程执行进入方法的时候，会将这个方法的一些信息作为栈帧压入方法栈中。一些信息可能有参数，返回地址(这个肯定是必要的，因为出栈的时候需要用到，不然无法返回了)。但栈帧出栈的时候就意味着这个方法执行完了，所以隐含意思就是一个栈帧对应着一次一个方法的执行，栈帧和一次一个方法的执行是同生死共命运的。

而我们也知道，对于局部变量来说，在方法执行完就会消失，所以局部变量和栈帧就有着同样的性质了，即局部变量，栈帧，一次一个方法的执行这三者是同时消亡的。所以把局部变量放入栈帧中是最合适不过的了，现实也是这么做的。这也解释了Java中为什么局部变量是存放在栈中的，想要跨越方法的边界，那么变量就必须放入堆中。

线程与方法栈

从操作系统层面来说，每个线程不独立拥有资源，但是它还是拥有一些必要的资源比如线程控制块(也不算资源)，用户栈，内核栈。。所以线程是拥有自己的栈的，也就是说每个线程执行过程中都拥有自己的方法调用栈，而栈帧是在这个方法栈中的，栈帧里面拥有着局部变量，所以可以说，每个线程的局部变量根本不是一个地址，所以就不会出现数据竞争了，所以局部变量是线程安全的。

线程封闭

因为局部变量不存在并发问题，现在也成为了一个解决并发问题的重要思路了，叫线程封闭。

采用线程封闭技术的案例非常多，例如从数据库连接池里获取的连接 Connection，在 JDBC 规范里并没有要求这个 Connection 必须是线程安全的。数据库连接池通过线程封闭技术，保证一个 Connection 一旦被一个线程获取之后，在这个线程关闭 Connection 之前的这段时间里，不会再分配给其他线程，从而保证了 Connection 不会有并发问题。

Java并发编程学习——创建多少线程才是合适的

2019-08-10T08:24:39.000Z

为什么使用多线程

减少延迟，提高吞吐量。

延迟指从发出请求到收到响应过程的时间，吞吐量指单位时间内能完成的请求个数。

多线程应用场景

想要降低延迟提高吞吐量主要有两个维度的方法，第一个是优化算法，第二个是最大化硬件的利用率。前者属于算法范畴，后者就和并发编程息息相关了。而对于计算机硬件来说最主要的就是两个硬件，一个是IO一个是CPU。在操作系统层面，操作系统已经为我们对硬件的利用率做了很大的优化，但是还是不够，在CPU与IO配合使用的利用率更加需要我们程序员去优化。也就是说，我们需要去解决CPU和IO设备综合利用率的问题

例如在单线程中，假设CPU和IO的执行时间相同，那么这个时候CPU和IO设备的利用率都是50%。

但在双线程中，CPU和IO设备执行时间都是一样的，这个时候，CPU在等待IO的时候又可以去执行下一个线程的，这个时候CPU和IO的利用率就是100%。

所以，如果 CPU 和 I/O 设备的利用率都很低，那么可以尝试通过增加线程来提高吞吐量。

在单核时代，多线程主要就是用来平衡 CPU 和 I/O 设备的。如果程序只有 CPU 计算，而没有 I/O 操作的话，多线程不但不会提升性能，还会使性能变得更差，原因是增加了线程切换的成本。但是在多核时代，这种纯计算型的程序也可以利用多线程来提升性能。为什么呢？因为利用多核可以降低响应时间。

例如计算 1+2+… … +100 亿的值，如果在 4 核的 CPU 上利用 4 个线程执行，线程 A 计算 [1，25 亿)，线程 B 计算 [25 亿，50 亿)，线程 C 计算 [50，75 亿)，线程 D 计算 [75 亿，100 亿]，之后汇总，那么理论上应该比一个线程计算 [1，100 亿] 快将近 4 倍，响应时间能够降到 25%。一个线程，对于 4 核的 CPU，CPU 的利用率只有 25%，而 4 个线程，则能够将 CPU 的利用率提高到 100%。

创建多少线程合适

创建多少线程合适需要考虑应用场景，通常情况下我们的程序都是由IO操作和CPU操作一起执行的，而IO操作相对于CPU操作来说是非常耗时的。所以大部分情况下，I/O 操作执行的时间相对于 CPU 计算来说都非常长，这种场景我们一般都称为 I/O 密集型计算。

和 I/O 密集型计算相对的就是 CPU 密集型计算了，CPU 密集型计算大部分场景下都是纯 CPU 计算。I/O 密集型程序和 CPU 密集型程序，计算最佳线程数的方法是不同的。

对于 CPU 密集型计算，多线程本质上是提升多核 CPU 的利用率，所以对于一个 4 核的 CPU，每个核一个线程，理论上创建 4 个线程就可以了，再多创建线程也只是增加线程切换的成本。所以，对于 CPU 密集型的计算场景，理论上线程的数量 =CPU 核数就是最合适的。不过在工程上，线程的数量一般会设置为CPU 核数 +1，这样的话，当线程因为偶尔的内存页失效或其他原因导致阻塞时，这个额外的线程可以顶上，从而保证 CPU 的利用率。

对于 I/O 密集型的计算场景，比如前面我们的例子中，如果 CPU 计算和 I/O 操作的耗时是 1:1，那么 2 个线程是最合适的。如果 CPU 计算和 I/O 操作的耗时是 1:2，那多少个线程合适呢？是 3 个线程，如下图所示：CPU 在 A、B、C 三个线程之间切换，对于线程 A，当 CPU 从 B、C 切换回来时，线程 A 正好执行完 I/O 操作。这样 CPU 和 I/O 设备的利用率都达到了 100%。

最佳线程数 =1 +（I/O 耗时 / CPU 耗时）

对于多核来说只需要乘上核数就行：最佳线程数 =CPU 核数 * [ 1 +（I/O 耗时 / CPU 耗时）]

Java并发编程学习——Java线程的生命周期

2019-08-10T05:16:09.000Z

通用线程模型

在操作系统中线程有五种状态，这也是通用的线程模型。这五种状态分别是初始状态(创建),可运行状态(就绪),运行状态,休眠状态(阻塞),终止状态(消亡)。

对于这五种状态，不同的编程语言会对他们进行简化合并或者细化，就比如Java把这五种状态进行了相应的更改。

Java线程模型

Java线程一共有六种状态，分别是：NEW（初始化状态），RUNNABLE（可运行 / 运行状态），BLOCKED（阻塞状态），WAITING（无时限等待），TIMED_WAITING（有时限等待），TERMINATED（终止状态）。

而对于BLOCKED，WAITTING，TIMED_WATTING这三种状态可以归于通用线程模型中的休眠状态(阻塞)，而对于通用线程中的运行状态和就绪(可运行状态)，在Java中则对他们进行了合并，合并成了Runnable状态。

Runnable与Blocked状态之间的转换

对于Runnable转换成Blocked状态只有一种情况，那就是在获取synchronized隐式锁失败的时候，线程会从可运行(Runnable)状态转换为Blocked阻塞状态。而当线程获取到了synchronized隐式锁的时候又会从Blocked状态转换到Runnable状态。

但是线程调用阻塞式API的时候不会从Runnable状态转换到Blocked状态，在操作系统层面，线程会进入休眠(阻塞状态)，但是在JVM层面，线程的状态是不会发生变化的，也就是说线程状态还是Runnable。JVM 层面并不关心操作系统调度相关的状态，因为在 JVM 看来，等待 CPU 使用权（操作系统层面此时处于可执行状态）与等待 I/O（操作系统层面此时处于休眠状态）没有区别，都是在等待某个资源，所以都归入了 RUNNABLE 状态。

Runnable和Waitting状态之间的转换

获得synchronized隐式锁的线程调用Object的wait方法
调用无参数的Thread.join(),其中的 join() 是一种线程同步方法，例如有一个线程对象 thread A，当调用 A.join() 的时候，执行这条语句的线程会等待 thread A 执行完，而等待中的这个线程，其状态会从 RUNNABLE 转换到 WAITING。当线程 thread A 执行完，原来等待它的线程又会从 WAITING 状态转换到 RUNNABLE。
调用 LockSupport.park() 方法。其中的 LockSupport 对象，也许你有点陌生，其实 Java 并发包中的锁，都是基于它实现的。调用 LockSupport.park() 方法，当前线程会阻塞，线程的状态会从 RUNNABLE 转换到 WAITING。调用 LockSupport.unpark(Thread thread) 可唤醒目标线程，目标线程的状态又会从 WAITING 状态转换到 RUNNABLE。

Runnable与Timed_Waitting状态之间的转换

调用带超时参数的 Thread.sleep(long millis) 方法
获得 synchronized 隐式锁的线程，调用带超时参数的 Object.wait(long timeout) 方法
调用带超时参数的 Thread.join(long millis) 方法
调用带超时参数的 LockSupport.parkNanos(Object blocker, long deadline) 方法；
调用带超时参数的 LockSupport.parkUntil(long deadline) 方法。

从New到Runnable状态

首先当线程创建的时候就是New状态，而创建线程有两种方式。

一是继承Thread类并重写run方法。

二是实现Runnable接口重写run方法并将该类作为创建Thread的参数。

// 自定义线程对象
class MyThread extends Thread {
  public void run() {
    // 线程需要执行的代码
    ......
  }
}
// 创建线程对象
MyThread myThread = new MyThread();

// 实现 Runnable 接口
class Runner implements Runnable {
  @Override
  public void run() {
    // 线程需要执行的代码
    ......
  }
}
// 创建线程对象
Thread thread = new Thread(new Runner());

而对于从New状态到Runnable状态只需要调用线程的start()方法。

从Runnable状态到Terminated状态

调用stop()或者interrupt()方法，但是对于stop方法官方已经废弃，因为stop方法会直接杀死线程，如果线程已经获得隐式锁，那么这锁也会消失，也就意味着，其他线程再也获取不到这个锁了。类似的方法还有 suspend() 和 resume() 方法，这两个方法同样也都不建议使用了。

而 interrupt() 方法就温柔多了，interrupt() 方法仅仅是通知线程，线程有机会执行一些后续操作，同时也可以无视这个通知。被 interrupt 的线程，是怎么收到通知的呢？一种是异常，另一种是主动检测。

比如有线程A和线程B，线程A调用了线程B的interrupt()方法，这个意思是指线程A告诉线程B——你现在被设置成了中断状态。但是线程B还可以进行操作(因为它有个isInterrupted来决定被中断之后执行的操作)

当线程 A 处于 WAITING、TIMED_WAITING 状态时，如果其他线程调用线程 A 的 interrupt() 方法，会使线程 A 返回到 RUNNABLE 状态，同时线程 A 的代码会触发 InterruptedException 异常。

上面我们提到转换到 WAITING、TIMED_WAITING 状态的触发条件，都是调用了类似 wait()、join()、sleep() 这样的方法，我们看这些方法的签名，发现都会 throws InterruptedException 这个异常。这个异常的触发条件就是：其他线程调用了该线程的 interrupt() 方法。

当线程 A 处于 RUNNABLE 状态时，并且阻塞在 java.nio.channels.InterruptibleChannel 上时，如果其他线程调用线程 A 的 interrupt() 方法，线程 A 会触发 java.nio.channels.ClosedByInterruptException 这个异常；而阻塞在 java.nio.channels.Selector 上时，如果其他线程调用线程 A 的 interrupt() 方法，线程 A 的 java.nio.channels.Selector 会立即返回。

上面这两种情况属于被中断的线程通过异常的方式获得了通知。还有一种是主动检测，如果线程处于 RUNNABLE 状态，并且没有阻塞在某个 I/O 操作上，例如中断计算圆周率的线程 A，这时就得依赖线程 A 主动检测中断状态了。如果其他线程调用线程 A 的 interrupt() 方法，那么线程 A 可以通过 isInterrupted() 方法，检测是不是自己被中断了。

Java并发编程学习——管程

2019-08-09T14:04:37.000Z

什么是管程

管程：管理共享变量和操作共享变量的过程。为了解决信号量配对的复杂性以及分散在程序中降低了程序的可读性，管程通过一种数据结构对共享变量和对共享变量的操作进行了封装。

管程和信号量是等价的，所谓等价指的是用管程能够实现信号量，也能用信号量实现管程。但是管程更容易使用，所以 Java 选择了管程。

在Java1.5之前提供的是synchronized，wait，notify和notifyAll，这是java管程实现的一部分。

MESA模型

在管程的发展史上，先后出现过三种不同的管程模型，分别是：Hasen 模型、Hoare 模型和 MESA 模型。其中，现在广泛应用的是 MESA 模型，并且 Java 管程的实现参考的也是 MESA 模型。

MESA模型实现互斥

这里的共享变量被封装起来了，其中对于共享变量queue的操作只能通过enq和deq，而这两个方法保证互斥性，只允许一个线程进入管程。

MESA墨香实现同步

对于同步则通过增加条件变量和相应的等待队列。

如果当条件变量不满足的时候则进入相应的等待队列，因为某个操作而导致条件允许的时候则唤醒相应的等待队列中的线程，并且再次获取锁来执行。因为要再次获取锁，所以这个条件只能是曾经满足过，所以当阻塞线程被唤醒再次获取锁需要执行的时候，有可能这个时候的条件又不允许了。

代码实现

对于入队操作，如果队列已满，就需要等待直到队列不满，所以这里用了notFull.await();。

对于出队操作，如果队列为空，就需要等待直到队列不空，所以就用了notEmpty.await();。

如果入队成功，那么队列就不空了，就需要通知条件变量：队列不空notEmpty对应的等待队列。

如果出队成功，那就队列就不满了，就需要通知条件变量：队列不满notFull对应的等待队列。

public class BlockedQueue<T>{
  final Lock lock =
    new ReentrantLock();
  // 条件变量：队列不满  
  final Condition notFull =
    lock.newCondition();
  // 条件变量：队列不空  
  final Condition notEmpty =
    lock.newCondition();

  // 入队
  void enq(T x) {
    lock.lock();
    try {
      while (队列已满){
        // 等待队列不满
        notFull.await();
      }  
      // 省略入队操作...
      // 入队后, 通知可出队
      notEmpty.signal();
    }finally {
      lock.unlock();
    }
  }
  // 出队
  void deq(){
    lock.lock();
    try {
      while (队列已空){
        // 等待队列不空
        notEmpty.await();
      }
      // 省略出队操作...
      // 出队后，通知可入队
      notFull.signal();
    }finally {
      lock.unlock();
    }  
  }
}

这里的await和signal就类似于wait和notify。

对于 MESA 管程来说，有一个编程范式，就是需要在一个 while 循环里面调用 wait()。这个是 MESA 管程特有的。

1
2
3

while(条件不满足) {
  wait();
}

Hasen 模型、Hoare 模型和 MESA 模型的一个核心区别就是当条件满足后，如何通知相关线程。管程要求同一时刻只允许一个线程执行，那当线程 T2 的操作使线程 T1 等待的条件满足时，T1 和 T2 究竟谁可以执行呢？

Hasen 模型里面，要求 notify() 放在代码的最后，这样 T2 通知完 T1 后，T2 就结束了，然后 T1 再执行，这样就能保证同一时刻只有一个线程执行。
Hoare 模型里面，T2 通知完 T1 后，T2 阻塞，T1 马上执行；等 T1 执行完，再唤醒 T2，也能保证同一时刻只有一个线程执行。但是相比 Hasen 模型，T2 多了一次阻塞唤醒操作。
MESA 管程里面，T2 通知完 T1 后，T2 还是会接着执行，T1 并不立即执行，仅仅是从条件变量的等待队列进到入口等待队列里面。这样做的好处是 notify() 不用放到代码的最后，T2 也没有多余的阻塞唤醒操作。但是也有个副作用，就是当 T1 再次执行的时候，可能曾经满足的条件，现在已经不满足了，所以需要以循环方式检验条件变量。

notify() 何时可以使用

满足以下三个条件：

所有等待线程拥有相同的等待条件
所有等待线程被唤醒之后，执行相同的操作。
只需要唤醒一个线程。

Java并发编程学习——安全性，活跃性以及性能问题

2019-08-09T06:11:27.000Z

安全性问题

在并发编程中需要考虑三个基本问题——安全性，活跃性以及性能。

所谓安全性就是指程序能否按照我们预期的执行。就比如线程安全这个概念，所谓线程安全和不安全无非就是指程序能否保证它的正确性，而这个正确性就是我们让程序按照我们所期望地执行。

而这种情况下只有存在共享数据并且该数据会发生变化的时候需要考虑安全性问题，通俗来讲就是是否存在多个线程对这个资源进行读写操作(至少有一个线程进行写操作)。

当多个线程同时访问同一数据，并且至少有一个线程会写这个数据的时候，如果我们不采取防护措施，那么就会导致并发 Bug，对此还有一个专业的术语，叫做数据竞争（Data Race）。

就比如以下的add10k方法，当多个线程调用的时候就会发生数据竞争。

public class Test {
  private long count = 0;
  void add10K() {
    int idx = 0;
    while(idx++ < 10000) {
      count += 1;
    }
  }
}

那是不是在访问数据的地方，我们加个锁保护一下就能解决所有的并发问题了呢？显然没有这么简单。例如，对于上面示例，我们稍作修改，增加两个被 synchronized 修饰的 get() 和 set() 方法， add10K() 方法里面通过 get() 和 set() 方法来访问 value 变量，修改后的代码如下所示。对于修改后的代码，所有访问共享变量 value 的地方，我们都增加了互斥锁，此时是不存在数据竞争的。但很显然修改后的 add10K() 方法并不是线程安全的。

public class Test {
  private long count = 0;
  synchronized long get(){
    return count；
  }
  synchronized void set(long v){
    count = v;
  }
  void add10K() {
    int idx = 0;
    while(idx++ < 10000) {
      set(get()+1)
    }
  }
}

我们来解读一下，这时候同时存在两个线程访问add10k方法然后同时进入while循环，然后同时调用get方法，但是因为get方法是synchronized修饰的所以同时只有一个线程能访问，比如这个时候线程A获得了优先权进行调用，读取到count为0，然后这个时候get方法执行完线程A释放锁，线程B获得了锁进入get方法也读取到count为0，然后可能这个时候线程B有执行了加一操作并且获得了set方法的锁进入set方法将count设置为1，这个时候可能线程A也执行了+1操作并且获得了线程B刚刚释放的锁来进行set操作，这个时候count又会被设置为1，其实本该结果为2(因为进行了两次加一操)，但是因为线程执行顺序的问题而导致程序不是按照我们期望的执行，所以这个是咸亨不安全的。

这种问题，有个官方的称呼，叫竞态条件（Race Condition）。所谓竞态条件，指的是程序的执行结果依赖线程执行的顺序。例如上面的例子，如果两个线程完全同时执行，那么结果是 1；如果两个线程是前后执行，那么结果就是 2。在并发环境里，线程的执行顺序是不确定的，如果程序存在竞态条件问题，那就意味着程序执行的结果是不确定的，而执行结果不确定这可是个大 Bug。

下面再结合一个例子来说明下竞态条件，就是前面文章中提到的转账操作。转账操作里面有个判断条件——转出金额不能大于账户余额，但在并发环境里面，如果不加控制，当多个线程同时对一个账号执行转出操作时，就有可能出现超额转出问题。假设账户 A 有余额 200，线程 1 和线程 2 都要从账户 A 转出 150，在下面的代码里，有可能线程 1 和线程 2 同时执行到第 6 行，这样线程 1 和线程 2 都会发现转出金额 150 小于账户余额 200，于是就会发生超额转出的情况。

class Account {
  private int balance;
  // 转账
  void transfer(
      Account target, int amt){
    if (this.balance > amt) {
      this.balance -= amt;
      target.balance += amt;
    }
  }
}

那面对数据竞争和竞态条件问题，又该如何保证线程的安全性呢？其实这两类问题，都可以用互斥这个技术方案，而实现互斥的方案有很多，CPU 提供了相关的互斥指令，操作系统、编程语言也会提供相关的 API。从逻辑上来看，我们可以统一归为：锁。

活跃性问题

所谓活跃性问题，指的是某个操作无法执行下去。我们常见的“死锁”就是一种典型的活跃性问题，当然除了死锁外，还有两种情况，分别是活锁和饥饿。

但有时线程虽然没有发生阻塞，但仍然会存在执行不下去的情况，这就是所谓的“活锁”。

可以类比现实世界里的例子，路人甲从左手边出门，路人乙从右手边进门，两人为了不相撞，互相谦让，路人甲让路走右手边，路人乙也让路走左手边，结果是两人又相撞了。这种情况，基本上谦让几次就解决了，因为人会交流啊。可是如果这种情况发生在编程世界了，就有可能会一直没完没了地“谦让”下去，成为没有发生阻塞但依然执行不下去的“活锁”。

解决“活锁”的方案很简单，谦让时，尝试等待一个随机的时间就可以了。例如上面的那个例子，路人甲走左手边发现前面有人，并不是立刻换到右手边，而是等待一个随机的时间后，再换到右手边；同样，路人乙也不是立刻切换路线，也是等待一个随机的时间再切换。由于路人甲和路人乙等待的时间是随机的，所以同时相撞后再次相撞的概率就很低了。“等待一个随机时间”的方案虽然很简单，却非常有效，Raft 这样知名的分布式一致性算法中也用到了它。

那“饥饿”该怎么去理解呢？所谓“饥饿”指的是线程因无法访问所需资源而无法执行下去的情况。“不患寡，而患不均”，如果线程优先级“不均”，在 CPU 繁忙的情况下，优先级低的线程得到执行的机会很小，就可能发生线程“饥饿”；持有锁的线程，如果执行的时间过长，也可能导致“饥饿”问题。

解决“饥饿”问题的方案很简单，有三种方案：一是保证资源充足，二是公平地分配资源，三就是避免持有锁的线程长时间执行。这三个方案中，方案一和方案三的适用场景比较有限，因为很多场景下，资源的稀缺性是没办法解决的，持有锁的线程执行的时间也很难缩短。倒是方案二的适用场景相对来说更多一些。

那如何公平地分配资源呢？在并发编程里，主要是使用公平锁。所谓公平锁，是一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程会优先获得资源。

性能问题

使用“锁”要非常小心，但是如果小心过度，也可能出“性能问题”。“锁”的过度使用可能导致串行化的范围过大，这样就不能够发挥多线程的优势了，而我们之所以使用多线程搞并发程序，为的就是提升性能。

所以我们要尽量减少串行，那串行对性能的影响是怎么样的呢？假设串行百分比是 5%，我们用多核多线程相比单核单线程能提速多少呢？

有个阿姆达尔（Amdahl）定律，代表了处理器并行运算之后效率提升的能力，它正好可以解决这个问题，具体公式如下：

公式里的 n 可以理解为 CPU 的核数，p 可以理解为并行百分比，那（1-p）就是串行百分比了，也就是我们假设的 5%。我们再假设 CPU 的核数（也就是 n）无穷大，那加速比 S 的极限就是 20。也就是说，如果我们的串行率是 5%，那么我们无论采用什么技术，最高也就只能提高 20 倍的性能。

所以使用锁的时候一定要关注对性能的影响。那怎么才能避免锁带来的性能问题呢？这个问题很复杂，Java SDK 并发包里之所以有那么多东西，有很大一部分原因就是要提升在某个特定领域的性能。

不过从方案层面，我们可以这样来解决这个问题。

第一，既然使用锁会带来性能问题，那最好的方案自然就是使用无锁的算法和数据结构了。在这方面有很多相关的技术，例如线程本地存储 (Thread Local Storage, TLS)、写入时复制 (Copy-on-write)、乐观锁等；Java 并发包里面的原子类也是一种无锁的数据结构；Disruptor 则是一个无锁的内存队列，性能都非常好……

第二，减少锁持有的时间。互斥锁本质上是将并行的程序串行化，所以要增加并行度，一定要减少持有锁的时间。这个方案具体的实现技术也有很多，例如使用细粒度的锁，一个典型的例子就是 Java 并发包里的 ConcurrentHashMap，它使用了所谓分段锁的技术（这个技术后面我们会详细介绍）；还可以使用读写锁，也就是读是无锁的，只有写的时候才会互斥。

性能方面的度量指标有很多，我觉得有三个指标非常重要，就是：吞吐量、延迟和并发量。

吞吐量：指的是单位时间内能处理的请求数量。吞吐量越高，说明性能越好。
延迟：指的是从发出请求到收到响应的时间。延迟越小，说明性能越好。
并发量：指的是能同时处理的请求数量，一般来说随着并发量的增加、延迟也会增加。所以延迟这个指标，一般都会是基于并发量来说的。例如并发量是 1000 的时候，延迟是 50 毫秒。

总结

总之并发编程从微观上来讲就是要关注原子性，可见性，顺序性的问题。从宏观上来讲就要关注安全性，活跃性，性能的问题。而微观上三个问题的目的都是为了解决安全性的问题，但是解决问题的同时还可能产生新的问题，这就是活跃性的问题，而如何利用三个微观问题去解决安全问题随之带来了性能问题。