为何要进行同步控制？

java允许多线程并发控制，当多个线程同时操作一个可共享的资源变量时（如数据的增删改查），将会导致数据不准确，相互之间产生冲突，相互之间产生差异，因此加入同步锁以避免在该线程没有完成操作之前，无法被其他线程的调用，从而保证了该变量在多线程中的正确性。
还言之就是如何保证变量的线程安全。

synchronized

  • 由于java的每个对象都有一个内置锁，synchronized关键字修饰代码块/方法/类时会锁住整个代码块/方法/类。
  • synchronized与static连用时，修饰方法和修饰类的效果是一样的。都会锁住整个类。
  • 独占锁，加锁和解锁的过程自动进行，易于操作，但不够灵活。
  • 可重入，因为加锁和解锁自动进行，不必担心最后是否释放锁。
  • 不可中断，对interrupt无响应。

volatile

  • volatile关键字为域变量的访问提供了一种免锁机制。
  • 使用volatile修饰域相当于告诉虚拟机该域可能会被其他线程更新。
  • 因此每次使用该域就要重新计算，而不是使用寄存器中的值。
  • volatile不会提供任何原子操作，它也不能用来修饰final类型的变。
  • java基础 volatile详解

ReentrantLock

  • 在JavaSE5.0中新增了一个java.util.concurrent包来支持同步。
  • ReentrantLock类是可重入、互斥、实现了Lock接口的锁，
  • 它与使用synchronized方法和快具有相同的基本行为和语义，并且扩展了其能力。
  • 独占锁，加锁和解锁的过程需要手动进行，不易操作，但非常灵活。
  • 重入时，加锁和解锁次数需一致，否则其他线程无法获得锁。
  • 可中断。
  • 获取锁时可以等待,在时间内获取到锁都可以，而只尝试一次就立即返回，无参时表示立即返回锁申请的结果。
    • lock.tryLock()
  • ReentrantLock类的常用方法有：
    • ReentrantLock() : 创建一个ReentrantLock实例
    • lock() : 获得锁
    • unlock() : 释放锁，通常放在finally代码块中

公平锁

ReentrantLock可以实现公平锁，也就是在锁上等待时间最长的线程将获得锁的使用权。

1
Lock lock = new ReentrantLock(true);//true公平锁，false为非公平，默认false

ThreadLocal

  • 使用ThreadLocal管理变量，则每一个使用该变量的线程都获得该变量的副本，副本之间相互独立，这样每一个线程都可以随意修改自己的变量副本，而不会对其他线程产生影响。把共享数据变为非共享数据，保证变量的线程安全。
  • 不是同步机制，但是都是为了解决多线程中相同变量的访问冲突问题。
  • ThreadLocal是采用以空间换时间的方式实现，同步机制是以时间换空间的方式实现
  • ThreadLocal 类的常用方法
    • ThreadLocal() : 创建一个线程本地变量
    • get() : 返回此线程局部变量的当前线程副本中的值
    • initialValue() : 返回此线程局部变量的当前线程的”初始值”
    • set(T value) : 将此线程局部变量的当前线程副本中的值设置为value

BlockingQueue

  • 在javaSE5.0版本中新增的java.util.concurrent包中BlockingQueue很好的解决了，如何高效安全“传输”数据的问题。
  • 常用队列有两种，当然根据不同情况，还有许多延伸类型队列
    • 先进先出（FIFO）：先插入的队列的元素也最先出队列，类似于排队的功能。从某种程度上来说这种队列也体现了一种公平性。
    • 后进先出（LIFO）：后插入队列的元素最先出队列，这种队列优先处理最近发生的事件。
  • 阻塞队列，通常是FIFO,当生产者和消费者速度不匹配时
    • 产大于消，那么生产者就会堵塞，以便消费者快速消费累计的数据。
    • 消大于产，那么消费者就会堵塞，防止消费者空转，产生额外的cpu浪费。
  • 主要方法
    • offer(E e):表示如果可能的话,将anObject加到BlockingQueue里,即如果BlockingQueue可以容纳,则返回true,否则返回false。（本方法不阻塞当前执行方法的线程）。当队列满时，会返回false。
    • offer(E e, long timeout, TimeUnit unit),可以设定等待的时间，如果在指定的时间内，还不能往队列中加入BlockingQueue，则返回失败。
    • add(E e):调用offer(E e)，只是当offer返回false时会抛出异常。
    • put(anObject):把anObject加到BlockingQueue里,如果BlockQueue没有空间,则调用此方法的线程被阻断直到BlockingQueue里面有空间再继续。当队列满时，会堵塞。
    • poll(long timeout, TimeUnit unit)：从BlockingQueue取出一个队首的对象，如果在指定时间内，队列一旦有数据可取，则立即返回队列中的数据。否则知道时间超时还没有数据可取，返回失败。
    • take():取走BlockingQueue里排在首位的对象,若BlockingQueue为空,阻断进入等待状态直到BlockingQueue有新的数据被加入。
    • drainTo():一次性从BlockingQueue获取所有可用的数据对象（还可以指定获取数据的个数）， 通过该方法，可以提升获取数据效率；不需要多次分批加锁或释放锁。

ArrayBlockingQueue

  • 基于数组的阻塞队列实现，在ArrayBlockingQueue内部，维护了一个定长数组，以便缓存队列中的数据对象，这是一个常用的阻塞队列，除了一个定长数组外，ArrayBlockingQueue内部还保存着两个整形变量，分别标识着队列的头部和尾部在数组中的位置。ArrayBlockingQueue在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；按照实现原理来分析，ArrayBlockingQueue完全可以采用分离锁，从而实现生产者和消费者操作的完全并行运行。Doug Lea之所以没这样去做，也许是因为ArrayBlockingQueue的数据写入和获取操作已经足够轻巧，以至于引入独立的锁机制，除了给代码带来额外的复杂性外，其在性能上完全占不到任何便宜。 ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。

LinkedBlockingQueue

  • 基于链表的阻塞队列，同ArrayListBlockingQueue类似，其内部也维持着一个数据缓冲队列（该队列由一个链表构成），当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。

需要注意的是，如果构造一个LinkedBlockingQueue对象，而没有指定其容量大小，LinkedBlockingQueue会默认一个类似无限大小的容量（Integer.MAX_VALUE），这样的话，如果生产者的速度一旦大于消费者的速度，也许还没有等到队列满阻塞产生，系统内存就有可能已被消耗殆尽了。

DelayQueue

  • DelayQueue中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。DelayQueue是一个没有大小限制的队列，因此往队列中插入数据的操作（生产者）永远不会被阻塞，而只有获取数据的操作（消费者）才会被阻塞。
  • 使用场景：DelayQueue使用场景较少，但都相当巧妙，常见的例子比如使用一个DelayQueue来管理一个超时未响应的连接队列。

PriorityBlockingQueue

  • 基于优先级的阻塞队列（优先级的判断通过构造函数传入的Compator对象来决定），但需要注意的是PriorityBlockingQueue并不会阻塞数据生产者，而只会在没有可消费的数据时，阻塞数据的消费者。因此使用的时候要特别注意，生产者生产数据的速度绝对不能快于消费者消费数据的速度，否则时间一长，会最终耗尽所有的可用堆内存空间。在实现PriorityBlockingQueue时，内部控制线程同步的锁采用的是公平锁。

SynchronousQueue

  • 一种无缓冲的等待队列，类似于无中介的直接交易，有点像原始社会中的生产者和消费者，生产者拿着产品去集市销售给产品的最终消费者，而消费者必须亲自去集市找到所要商品的直接生产者，如果一方没有找到合适的目标，那么对不起，大家都在集市等待。相对于有缓冲的BlockingQueue来说，少了一个中间经销商的环节（缓冲区），如果有经销商，生产者直接把产品批发给经销商，而无需在意经销商最终会将这些产品卖给那些消费者，由于经销商可以库存一部分商品，因此相对于直接交易模式，总体来说采用中间经销商的模式会吞吐量高一些（可以批量买卖）；但另一方面，又因为经销商的引入，使得产品从生产者到消费者中间增加了额外的交易环节，单个产品的及时响应性能可能会降低。
  • 声明一个SynchronousQueue有两种不同的方式，它们之间有着不太一样的行为。公平模式和非公平模式的区别:
    • 如果采用公平模式：SynchronousQueue会采用公平锁，并配合一个FIFO队列来阻塞多余的生产者和消费者，从而体系整体的公平策略；
    • 但如果是非公平模式（SynchronousQueue默认）：SynchronousQueue采用非公平锁，同时配合一个LIFO队列来管理多余的生产者和消费者，而后一种模式，如果生产者和消费者的处理速度有差距，则很容易出现饥渴的情况，即可能有某些生产者或者是消费者的数据永远都得不到处理。

原子变量

  • 在java的java.util.concurrent.atomic包中提供了创建了原子类型变量的工具类
  • Atomicxxxx都是CAS（compareAndSwap）实现的原子性，来保证线程安全性。