并发编程

2018, Sep 16    

并发编程

共享资源：多个线程同时对同一份资源进行访问（读写操作） 线程安全：多个线程共享资源时，都能体现出和单线程一样的正确性-所见即所知 线程安全问题：多线程共享资源时，出现脏数据或不可遇见的结果。（线程安全问题实际上是没有任何同步措施地共享资源）

多线程活跃性问题：

  • 死锁：多个线程互相持有对方所需要的资源,导致这些线程处于等待状态,无法前往执行
  • 活锁：资源不断在两个线程中跳动，没有一个线程可以同时拿到所有资源而正常执行
  • 饥饿：一个线程，由于种种原因，一直无法获得所需要的资源

并发级别分类：

  • 阻塞：在其它线程释放资源之前，当前线程无法执行

  • 无饥饿：要想获得资源，所有线程都要排队，这样所有线程都有机会执行

  • 无障碍：最弱无阻塞调度，所有线程都可以进入临界区，如果一起修改共享资源则各自都进行回滚操作

  • 无锁：无锁没有对资源进行锁定 ，所有线程都可以进入临界区，尝试修改，永不言弃，且保证必有一个线程在有限步类能完成操作离开临界区

  • 无等待：在无锁的基础上进行扩展，要求所有线程都必须在有限步内完成

一般说来，确保线程安全的方法有这几个：

（1）互斥同步、（2）非阻塞同步、（3）无同步方案 互斥同步(阻塞同步)：锁（sychronized、Lock接口）、信号量、并发工具类（CounDownLatch、CyclicBarry） 非阻塞同步：volatile、原子类 无同步方案（不涉及共享数据的代码）：Thread Local、可重入代码(纯代码) 注：可重入代码最简单的理解就是任何变量都是局部变量

Java 锁机制(Java线程锁有哪些，各自的优势、劣势和使用场景)

（一）Java中往往是按照是否含有某一特性来定义锁，我们通过特性将锁进行分组归类 。

悲观锁：在处理数据之前加锁，整个数据处理过程中，数据处于所动状态

  • 优势：先取锁再访问”的保守策略 ，数据处理的安全提供了保证
  • 劣势：对于只读，降低了并行性 ，增加产生死锁的机会
  • 场景：悲观锁适合写操作多的场景，先加锁可以保证写操作时数据正确
  • 代表：synchronized关键字和Lock接口的实现类

乐观锁：访问数据时不加锁，只是在更新数据的时，才会对数据冲突与否进行检测。[如果这个数据没有被更新，当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新，则根据不同的实现方式执行不同的操作（例如报错或者自动重试）]

  • 优势：访问数据时省去了锁的开销 ，不会产生死锁
  • 劣势：果经常产生冲突 ，性能会大大降低
  • 场景：乐观锁适合读操作多的场景，不加锁的特点能够使其读操作的性能大幅提升
  • 代表：原子类

自旋锁：当前线程无法获得锁时，不立刻阻塞，而是进行若干次空循环（默认是10次 ）

  • 优势：锁被占用的时间很短，那么当前线程就可以不阻塞而直接获取同步资源
  • 劣势：不能代替阻塞 ，锁被占用的时间很长 ，自旋会白白浪费处理器资源
  • 代表：AtomicInteger中调用unsafe进行自增操作的源码中的do-while循环就是一个自旋操作 、TicketLock、CLHlock和MCSlock

适应性自旋锁：自适应意味着自旋的时间不再固定了，而是由前 一次在同一个锁上的自旋时间及锁的拥有者的状态来决定

无锁 、偏向锁、轻量级锁 、 重量级锁：这四种锁是指锁的状态，专门针对synchronized的

公平锁：线程获取锁的顺序，按照请求锁的时间，线程直接进入队列中排队 ，先到先得

  • 优势：等待锁的线程不会出现饥饿
  • 劣势：整体吞吐效率相对非公平锁要低 （等待队列中除第一个线程以外的所有线程都会阻塞，CPU唤醒阻塞线程的开销比非公平锁大）
  • 场景：有公平性的业务需求
  • 代表：ReentrantLock pairLock = new ReentrantLock(true);

非公平锁：直接尝试获取锁，获取不到才会到等待队列的队尾等待 ，先到不一定先得

  • 优势：可以减少唤起线程的开销，整体的吞吐效率高 （线程有几率不阻塞直接获得锁，CPU不必唤醒所有线程 ）
  • 劣势：等待队列中的线程可能会饥饿，或者等很久才会获得锁
  • 场景：在没有公平性要求的前提下尽量使用非公平锁
  • 代表：sychronized、ReentrantLock pairLock = new ReentrantLock(false)或new ReentrantLock();

可重入锁（又名递归锁 ）：当一个线程再次获取它已经已经获取的锁时，不会被阻塞，这种锁就是可重入锁

  • 优势：可一定程度避免死锁
  • 劣势：
  • 场景：同一个线程在外层方法获取锁的时候，再进入该线程的内层方法还需要获取锁
  • 代表：ReentrantLock和synchronized

不可重入锁:当一个线程再次获取它已经已经获取的锁时，会被阻塞，这种锁就是可重入锁

  • 优势：
  • 劣势：一个线程获取到一把锁之后,该线程是无法调用其他加了该锁的方法.这种情况,容易造成死锁
  • 场景：
  • 代表：NonReentrantLock

共享锁：该锁一次只能被多个线程所持有 [如果线程T对数据A加上共享锁后，则其他线程只能对A再加共享锁，不能加排它锁。获得共享锁的线程只能读数据，不能修改数据]

  • 优势： 提高读的并发性
  • 劣势： 获得该共享锁后，只能读
  • 场景：多读少写
  • 代表：ReentrantReadWriteLock.ReadLock

排它锁（独占锁、互斥锁）：该锁一次只能被一个线程所持有

  • 优势： 见悲观锁
  • 劣势：见悲观锁
  • 场景：见悲观锁
  • 代表：synchronized和Lock的实现类 、ReentrantReadWriteLock.WriteLock

（二）Java实现锁有两种语法，一种是synchronized语句，另外一种是reentrantlock关键字 （Lock接口的实现类）

synchronized实现后文有讲

Lock接口：Java SE 5之后，并发包中新增了Lock接口（以及相关实现类）用来实现锁功能，它提供了与synchronized关键字类似的同步功能，只是在使用时需要显式地获取和释放锁。虽然它缺少了（通过synchronized块或者方法所提供的）隐式获取释放锁的便捷性，但是却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种synchronized关键字所不具备的同步特性。

几种同步的实现对比

锁的类型 优势 劣势 使用场景
synchronized 同步操作简单 排它锁、会导致上下文切换 一般的同步需求用它。只有在确定锁机制是当前多线程程序的性能瓶颈时，才考虑使用其他机制
ReentrantLock （ReentrantLock与synchronized性能相差无几 ） 在高并发量的条件下，synchronized性能会迅速下降几十倍，而ReentrantLock的性能却能依然维持一个水准 ReentrantLock加锁后需要手动进行解锁 高并发量情况下使用ReentrantLock
Semaphore 允许多个线程同时访问某一资源 释放锁的操作也必须手动完成 多个临界资源的访问
Atomic 比锁的方式性能优越，没有锁竞争的开销 ABA问题
CAS的缺点 https://www.cnblogs.com/charlesblc/p/5994162.html		 只有一个共享变量时

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

java什么时候发生死锁（为什么产生死锁）?如何避免死锁?

多个线程互相持有对方所需要的资源,导致这些线程处于等待状态,无法前往执行。这就会导致死锁 java发生死锁的一些情况：交叉锁导致程序出现死锁、系统假死（死循环引起的死锁） 注意：严格来说，死循环导致的假死，算不上真正的死锁，但是某个线程对CPU消耗过多，导致其他线程等待CPU、内存等资源陷入死锁等待。

Java对象头：

  • 作用：synchronized给同步资源加的锁就在Java对象头里

  • 分析：Hotspot的对象头主要包括两部分数据：Mark Word（标记字段）、class Pointer（类型指针）。

    1. Mark Word：大小=xx位(JVM)bit，默认存储对象的HashCode，分代年龄和锁标志位信息。

      锁状态 存储内容 标志位
      无锁 对象的hashCode、对象分代年龄、是否是偏向锁（0） 01
      偏向锁 偏向线程ID、偏向时间戳、对象分代年龄、是否是偏向锁（1） 01
      轻量级锁 指向栈中锁记录的指针 00
      重量级锁 指向互斥量（重量级锁）的指针 10

    2. class Pointer：数组类型对象的大小=2*xx位(JVM)bit，非数组类型对象的大小=xx位(JVM)bit，对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

Monitor：

  • 作用：每一个Java对象就有一把看不见的锁，称为内部锁或者Monitor锁 。每一个线程都有一个可用monitor record列表 ，每一个被锁住的对象都会和一个monitor关联 。

synchronized 有4种锁的状态：无锁、偏向锁、轻量级锁和重量级锁 ，这几个状态会随着竞争情况逐渐升级，锁状态只能升级不能降级

无锁：无锁没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。 （CAS原理及应用即是无锁的实现 ）

  • 解决问题：锁无法全面代替有锁，但无锁在某些场合下的性能是非常高的
  • 何时升级为无锁：
  • 如何升级为无锁：

偏向锁：偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。

  • 解决问题：在只有一个线程执行同步代码块时能够提高性能
  • 何时升级为偏向锁：当一个线程访问同步代码块并获取锁时
  • 如何升级为偏向锁：在Mark Word里存储锁偏向的线程ID。在线程进入和退出同步块时不再通过CAS操作来加锁和解锁，而是检测Mark Word里是否存储着指向当前线程的偏向锁 （偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令即可 ）

轻量级锁：简单地将对象头部作为指针，指向持有锁的线程堆栈的内部，来判断一个线程是否持有对象锁

  • 解决问题：偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能
  • 何时升级升级为轻量级锁：当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁
  • 如何升级为轻量级锁：

重量级锁：

  • 解决问题：共享资源时确保线程安全
  • 何时升级为重量级锁：一个线程在持有锁，一个在自旋，又有第三个来访时，轻量级锁升级为重量级锁。
  • 如何升级为重量级锁：

综上，偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作。而轻量级锁是通过用CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒而影响性能。重量级锁是将除了拥有锁的线程以外的线程都阻塞。

volatile，synchronized的区别

synchronized，会引起线程阻塞，带来线程上下文的切换开销，太笨重 volatile是非阻塞算法，不会造成线程上下文的切换 除此之外： (1)原子性，volatile无法保证原子性；synchronized可以保证代码的原子性 (2)可见性，两者均可以保证可见性。synchronized通过JVM指令monitor enter、monitor exist推出时将共享资源刷新到主内存中； volatile使用机器指令lock

并发包用到那些？

​ Atomic : AtomicInteger Locks : Lock, Condition, ReadWriteLock Collections : Queue, ConcurrentMap Executer : Future, Callable, Executor Tools : CountDownLatch, CyclicBarrier, Semaphore

Atom类实现原理?cas阐述？cas操作（cas操作是哪个包里的）是怎么实现的，为什么是原子性的?cas的问题？

Atom类实现原理:通过CAS乐观锁保证原子性，通过自旋保证当次修改的最终修改成功

cas（比较和交换）：是一种无锁算法。在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。 CAS算法涉及到三个操作数：CAS(V,E,N)，V表示要更新的变量、E表示预期值、N表示新值。当且仅当 V 的值等于 E 时，CAS通过原子方式用新值N来更新V的值（“比较+更新”整体是一个原子操作），否则不会执行任何操作。一般情况下，“更新”是一个不断重试的操作。
cas的实现:调用了Unsafe类（这个类封装了一些类似指针的操作，它可以获取并操作内存的数据），Unsafe的整个“比较+更新”操作封装在compareAndSwapInt()中，在JNI里是借助于一个CPU指令完成的，属于原子操作。 CAS的问题:CAS虽然很高效，但是它也存在三大问题，这里也简单说一下：

ABA问题。CAS需要在操作值的时候检查内存值是否发生变化，没有发生变化才会更新内存值。但是如果内存值原来是A，后来变成了B，然后又变成了A，那么CAS进行检查时会发现值没有发生变化，但是实际上是有变化的。ABA问题的解决思路就是在变量前面添加版本号，每次变量更新的时候都把版本号加一，这样变化过程就从“A－B－A”变成了“1A－2B－3A”。

  • JDK从1.5开始提供了AtomicStampedReference类来解决ABA问题，具体操作封装在compareAndSet()中。compareAndSet()首先检查当前引用和当前标志与预期引用和预期标志是否相等，如果都相等，则以原子方式将引用值和标志的值设置为给定的更新值。

循环时间长开销大。CAS操作如果长时间不成功，会导致其一直自旋，给CPU带来非常大的开销。

只能保证一个共享变量的原子操作。对一个共享变量执行操作时，CAS能够保证原子操作，但是对多个共享变量操作时，CAS是无法保证操作的原子性的。

  • Java从1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行CAS操作。

ThreadLocal？应用场景？

ThreadLocal 在Java 开发中非常常见，一般在一下情况中会使用到ThreadLocal。

  • 在进行对象跨层传递的时候，可以考虑使用ThreadLocal，避免方法多次传递，打破层次间的约束。

  • 线程间数据隔离

  • 进行事物操作，用于存储线程事物信息

    ThreadLocal并不是解决多线程下共享资源的技术，一般情况下，每一个线程的ThreadLocal存储了一个对象的引用，那么其还将面临资源竞争，数据不一致等并发问题。

    Thread 类中有一个threadLocals和一个inheritableThreadLocals。它们都是ThreadLocalMap类型的变量，而ThreadLocalMap是一个定制化的Hashmap。在默认情况下，每个线程都是null，只有当前线程第一次调用ThreadLocal的set或get方法时才会创建它们。其实每个线程的本地变量不是存放在ThreadLocal实例里面，而是存放在具体的线程内存空间中。ThreadLocal就是一个工具壳，它是通过set方法把value值放入线程的threadLocalhs里面并存放起来，当调用线程调用它的get方法时，再从当前线程的threadLocals变量里面并将其拿出来使用。如果调用线程一直不终止，那么这个本地变量会一直存放在调用线程的threadLocals变量里面，所以当不需要使用本地变量时可以通过调用ThreadLocal变量的remove方法，从当前线程的threadLocals里面删除本地变量。threadLocals是一个HashMap结构，其中key就是当前ThreadLocal的实例对象引用，value是通过set方法传递的值。

分布式锁

ZooKeeper是一个订阅中心（注册中心） ,客户端注册监听它关心的目录节点，当目录节点发生变化时，ZooKeeper会通知客户端

加锁流程

1.在我们的资源目录下创建一个节点:比如这里创建一个/0000000002这个节点，这个节点需要设置为EPHEMERAL_SEQUENTIAL也就是临时节点并且有序。

2.获取当前目录下所有子节点，判断自己的节点是否位于子节点第一个。

如果是第一个，则获取到锁，那么可以返回。

如果不是第一个，则证明前面已经有人获取到锁了，那么需要获取自己节点的前一个节点。/0000000002的前一个节点是/0000000001，我们获取到这个节点之后，再上面注册Watcher(这里的watcher其实调用的是object.notifyAll(),用来解除阻塞)。

4.object.wait(timeout)或object.wait():进行阻塞等待这里和我们第5步的watcher相对应。

# Java