并发

并发

JMM内存模型

jmm是多线程模式下java定义的内存规范，屏蔽各种系统下内存模型的差异。  

JMM如何解决原子性、有序性、可见性。

有序性和可见性：jvm为了提高cpu利用率以及性能，可能会指令进行重排序。可以分别使用优化屏障和内存屏障这两个机制来解决。
    CPU的乱序执行，本质还是，由于在多CPU的机器上，每个CPU都存在cache，当一个特定数据第一次被特定一个 CPU获取时，由于在该CPU缓存中不存在，就会从内存中去获取，被加载到CPU高速缓存中后就能从缓存中快速访 问。当某个CPU进行写操作时，它必须确保其他的CPU已经将这个数据从他们的缓存中移除，这样才能让其他CPU 安全的修改数据。显然，存在多个cache时，我们必须通过一个cache一致性协议来避免数据不一致的问题，而这个通讯的过程就可能导致乱序访问的问题，也就是运行时的内存乱序访问。
    现在的CPU架构都提供了内存屏障功能，在x86的cpu中，实现了相应的内存屏障 写屏障(store barrier)、读屏障(load barrier)和全屏障(Full Barrier)，主要的作用是  防止指令之间的重排序。
    store barrier——称为写屏障，相当于storestore barrier, 强制所有在storestore内存屏障之前的所有执行，都要在该 内存屏障之前执行，并发送缓存失效的信号。所有在storestore barrier指令之后的store指令，都必须在 storestore barrier屏障之前的指令执行完后再被执行。也就是进制了写屏障前后的指令进行重排序，是的所有 store barrier之前发生的内存更新都是可见的（这里的可见指的是修改值可见以及操作结果可见）
    load barrier——称为读屏障，相当于loadload barrier，强制所有在load barrier读屏障之后的load指令，都在load barrier屏障之后执行。也就是进制对load barrier读屏障前后的load指令进行重排序， 配合store barrier，使得所 有store barrier之前发生的内存更新，对loadbarrier之后的load操作是可见的。
    full barrier——称为全屏障，相当于storeload，是一个全能型的屏障，因为它同时具备前面两种屏障的效果。强制了 所有在storeloadbarrier之前的store/load指令，都在该屏障之前被执行，所有在该屏障之后的的store/load指 令，都在该屏障之后被执行。禁止对storeload屏障前后的指令进行重排序。
    总结：内存屏障只是解决顺序一致性问题，不解决缓存一致性问题，缓存一致性是由cpu的缓存锁以及MESI协议来 完成的。而缓存一致性协议只关心缓存一致性，不关心顺序一致性。所以这是两个问题。
    在编译器层面，通过volatile关键字，取消编译器层面的缓存和重排序。保证编译程序时在优化屏障之前的指令不 会在优化屏障之后执                           行。这就保证了编译时期的优化不会影响到实际代码逻辑顺序。
    在JMM中把内存屏障指令分为4类，通过在不同的语义下使用不同的内存屏障来进制特定类型的处理器重排序，从 而来保证内存的可见性
    LoadLoad Barriers—load1 ; LoadLoad; load2 , 确保load1数据的装载优先于load2及所有后续装载指令的装载 。
    StoreStore Barriers—store1;storestore;store2 , 确保store1数据对其他处理器可见优先于store2及所有后续存储 指令的存储。
    LoadStore Barries—load1;loadstore;store2, 确保load1数据装载优先于store2以及后续的存储指令刷新到内存。
    StoreLoad Barries—store1;storeload;load2, 确保store1数据对其他处理器变得可见， 优先于load2及所有后续 装载指令的装载；这条内存屏障指令是一个全能型的屏障，在前面讲cpu层面的内存屏障的时候有提到。它同时具有其他3条屏障的效果。 
 
 原子性：synchronized保证原子性
              jdk1.6以后采用偏向锁、轻量锁、重量锁保证原子性问题。
  偏向锁过程：
偏向锁存在竞争就会升级到轻量级锁 
轻量锁到重量锁 

重量锁执行锁过程：每个对象都有一个monitor，monitor本质上是依赖于底层操作系统的Muter lock实现，在hotspot虚拟机中通过ObjectMonitor类实现monitor。当一个线程想占重量锁时，需要cas操作通过monitorentor抢占monitor监视器，如成功则得到锁执行，否则进入CXQ队列等待， 当线程执行monitorexit之后会将cxq队列中获取一个线程任务放到entryList中，然后从entryList中获取一个线程任务去抢占锁。（ owner：指向一个持有当前monitor的ObjectWaiter对象（每个等待锁的线程都会被封装成ObjectWaiter对象）。 2） _cxq ：存储ObjectWaiter对象的单向列表。多线程竞争锁时，会先进入此队列中。 3） _EntryList：存储处于Blocked状态的ObjectWaiter对象列表。 4） _WaitSet：存储wait状态的ObjectWaiter对象列表。）当执行wait时，线程将会被放到一个waitset集合中，当被notify之后会将waitset集合中的线程放到entryList中然后从entryList拿一个线程去抢占锁。（_cxq→entryList→cas→park→unpark）

锁类型	优点	缺点	适用场景
偏向锁	加锁、解锁不需要额外资源消耗，效率较高	如果线程间存在锁竞争，会带来额外的解锁消耗	适用只有一个线程访问同步块的情景
轻量级锁	竞争的线程不会阻塞，提高了程序响应速度	如果获取锁失败，会进入自旋消耗cpu	针对锁占用时间短，对响应时间比较敏感的情况
重量级锁	线程竞争不使用自旋，不消耗cpu	线程会被阻塞，影响响应时间	锁占用时间较长，对吞吐量要求较高

volatile和synchronized

volatile：保证有序性、可见性；
synchronized：保证原子性，可见性，有序性；
final：保证可见性；

Lock

Reentrantlock比较synchronized有以下特点
       1.jdk实现，而synchronized是关键字； 
       2.lock()和unlock灵活得到锁和释放锁，而synchronized是被动释放锁——方法结束和异常报错。
       3.lock可以判断锁的状态。
       4.有公平锁和非公平锁，synchronized非公平锁。
ReentrantLock：用（aqs）abstractQueuedSynchronizer类实现（fifo队列）； 双向链表结构）封装了线程和线程持有状态，如果多线程执行lock就把阻塞的线程封装成一个node放进aqs中，调用part()方法让线程阻塞，node属性prev和next。
lock完成过程——用cas判断并且修改reentrantLock的state是不是无锁状态（0：无；1：有；），如果无锁状态则将当前线程设置成aqs中的一个exclusiveOwnerThread属性，表示当前获取锁的线程；否则有锁状态则让当前线程tryAcquire(arg)尝试获取锁，如果没有锁则获取成功，如果有锁并且是当前线程则获取重入锁，否则获取锁失败——把当前线程封装一个node加入到aqs队尾。如果此时aqs只有一个线程head，则让head自旋获取锁——如果获取锁成功则把head.next变成head，否则判断node属性waitStatus=SIGNAL（-1）挂起线程。
unlock完成过程——tryRelease尝试释放锁，如果exclusiveOwnerThread不等于当前线程，报异常。如果state=0,释放成功，否则失败。失败之后将aqs中head拿出来并且它的waitStatus!=0才去释放锁——将head的waitStatus设置0，然后将离head最近的并且note.waitStatus<0的一个node唤醒。
condition中await——在lock和unlock方法中使用，会释放当前node所持有的锁，并把node节点从aqs队列加入await队列尾部中，并且使node阻塞。
condition中signal——拿到await队列中的第一个节点放入aqs队列中并唤醒。

CAS

compareAndSet底层调用了unsafe.compareAndSwapObject(this,tailOffset,expect,update);表示如果expect这个期待的值和内存中tailOffset地址中的值相等的话，就用update值替换tailOffset地址中的值。

 

转载于:https://my.oschina.net/yaojianpeng/blog/3076630