wordpress list,seo软件排行榜前十名,免费博客网站,软装素材网站有哪些Java并发一、锁1. 偏向锁1. 思想背景来源#xff1a;HotSpot的作者经过研究发现#xff0c;大多数情况下#xff0c;锁不仅不存在多线程竞争#xff0c;而且总是由同 一线程多次获得#xff0c;为了让线程获得锁的代价更低而引入了偏向锁。原理#xff1a;在对象头和栈帧…Java并发一、锁1. 偏向锁1. 思想背景来源HotSpot的作者经过研究发现大多数情况下锁不仅不存在多线程竞争而且总是由同 一线程多次获得为了让线程获得锁的代价更低而引入了偏向锁。原理在对象头和栈帧中的锁记录里存储锁偏向的线程ID以后该线程在进入和退出 同步块时不需要进行CAS操作来加锁和解锁只需简单地测试一下对象头的Mark Word里是否 存储着指向当前线程的偏向锁。悟偏向锁的来源就是为了节省当同一个线程访问临界区资源的时候频繁CAS加锁解锁操作的开支同样这也是偏向锁使用的场景即只有一个线程访问临界区资源的情况Java对象头中的Mark Word结构image2. 偏向锁的加锁当一个线程访问同步块并 获取锁时会在对象头和栈帧中的锁记录里存储锁偏向的线程ID以后该线程在进入和退出 同步块时不需要进行CAS操作来加锁和解锁只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁如果当前对象头的线程ID指向了该线程那么说明已经获得了锁否则判断对象头中的Mark Word锁的标识是否是偏向锁(对应就是锁标志位为01是否是偏向锁为1)如果是偏向锁那么会使用CAS将线程ID指向该线程否则则使用CAS竞争锁(说明此时是更高级的轻量锁或者重量锁需要竞争才行)最顺利的情况就是线程ID指向该线程这就对应只有一个线程频繁访问临界区资源的情况此时能够最大程度的减少CAS操作3.偏向锁的撤销偏向锁使用了一种等到竞争出现才释放锁的机制所以当其他线程尝试竞争偏向锁时 持有偏向锁的线程才会释放锁。偏向锁的撤销需要等待全局安全点(在这个时间点上没有正 在执行的字节码)首先暂停拥有偏向锁的线程然后检查持有偏向锁的线程是否活着如果不处于活动状态则将对象头设置成无锁状态否则拥有偏向锁的栈会被执行遍历偏向对象的锁记录栈中的锁记录和对象头的Mark Word进行更改要么重新偏向于其他线程要么恢复到无锁要么标记对象不适合作为偏向锁(此时需要升级锁)最后唤醒暂停的线程4. 过程图image2. 轻量锁1. 思想背景起源由于线程的阻塞/唤醒需要CPU在用户态和内核态间切换频繁的转换对CPU负担很重进而对并发性能带来很大的影响原理在只有两个线程并发访问资源区是一个持有锁另一个进行自旋等待2. 轻量锁加锁线程在执行同步块之前JVM会先在当前线程的栈帧中创建用于存储锁记录的空间并将对象头中的Mark Word复制到锁记录中(Displaced Mark Word-即被取代的Mark Word)做一份拷贝拷贝成功后线程尝试使用CAS将对象头的Mark Word替换为指向锁记录的指针(将对象头的Mark Word更新为指向锁记录的指针并将锁记录里的Owner指针指向Object Mark Word)如果更新成功当前线程获得锁继续执行同步方法如果更新失败表示其他线程竞争锁当前线程便尝试使用自旋来获取锁若自旋后没有获得锁此时轻量级锁会升级为重量级锁当前线程会被阻塞3. 轻量级锁解锁解锁时会使用CAS操作将Displaced Mark Word替换回到对象头如果解锁成功则表示没有竞争发生如果解锁失败表示当前锁存在竞争锁会膨胀成重量级锁需要在释放锁的同时唤醒被阻塞的线程之后线程间要根据重量级锁规则重新竞争重量级锁4. 流程图image3. 三种锁比较image二、处理器和Java中原子性操作的实现1. 处理器原子性操作的实现处理器级别内存操作的原子性保证有两种机制总线锁定和缓存锁定。(注意处理器会自动保证基本的内存操作的原子性即对于内存中某一个地址数据的访问时保证同一时刻只有一个处理器可以)1. 总线锁总线锁比较简单粗暴对于需要限制的共享变量通过LOCK信号使得在操作该贡献变量的时候一个处理器独占共享内存2. 缓存锁总线锁使得只能有一个处理器访问内存其他处理器不能够操作内存里的其他数据属于“一刀切”“一棒子打死”的做法所以开销比较大。所谓“缓存锁定”是指内存区域如果被缓存在处理器的缓存 行中并且在Lock操作期间被锁定那么当它执行锁操作回写到内存时处理器不在总线上声 言LOCK信号而是修改内部的内存地址并允许它的缓存一致性机制来保证操作的原子 性因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据当其他处理器回写已被锁定的缓存行的数据时会使缓存行无效从而使他们重新从内存中获取数据。虽然缓存锁更好但是总线锁并没有完全弃用。有些情况缓存锁没有办法发挥此时便需要总线锁了。2. Java中实现原子操作的原理不管是加锁还是其他方法Java都是使用循环CAS的方式实现原子操作的。三、Java内存模型一、内存模型JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看JMM定义了线程和主内存之间的抽象关系线程之间的共享变量存储在主内存(Main Memory)中每个线程都有一个私有的本地内存(Local Memory)本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。1. 指令重排序在执行程序时为了提高性能编译器和处理器常常会对指令做重排序编译器优化的重排序编译器在不改变串行语义的前提下可以安排语句的执行顺序指令级并行的重排序现代处理器才用了指令级的并行技术(流水线技术)来将多条指令重叠执行。如果不存在数据依赖性处理器可以改变语句对应 机器指令的执行顺序。内存系统的重排序由于处理器使用缓存和读/写缓冲区这使得加载和存储操作看上 去可能是在乱序执行。(我们不用关注内存系统的重排序其不再JMM的覆盖范围)2. 数据依赖性如果两个操作中至少有一个操作是写操作的话那么就说这两个操作之间具有数据依赖性。编译器和处理器在重排序时会遵守数据依赖性编译器和处理器不会改变存在数据依赖关系的两个操作的执行顺序。(这里的顺序依赖性只针对单线程下的指令)即指令重排序必须保证单线程下的串行语义。3. 顺序一致性当程序未正确同步时就可能存在数据竞争所谓数据竞争就是1. 在一个线程中写入一个变量 2. 在另一个线程中读同一个变量 3. 且写和读没有通过同步来排序而正确同步的线程不会发生数据竞争。如果程序是正确同步的那么程序的执行具有顺序一致性。顺序一致性模型有两条规则一个线程中的所有操作必须按照程序的顺序来执行。(不管程序是否同步)所有线程都只能看到一个单一的操作执行顺序。在顺序一致性内存模型中每个操作都必须原子执行且立刻对所有线程可见。可见这两条规则是非常理想化的如果线程的操作是按照我门程序中写的顺序执行且不同线程之间的操作立刻可见那么并发编程会是一件很容易的事情。但是很遗憾JMM一条也没有遵守顺序一致性模型。对于第一条编译器和处理器都会对指令进行重排序所以执行顺序和书写顺序并不相同对于第二条更不可能了。但是在Java中同步了的程序具有顺序一致性的效果[图片上传失败...(image-2082d2-1583984997624)]因此Java保证只要是同步了的代码程序员可以把他当做是在顺序一致性模型下运行的一样二、Volatile内存语义volatile变量读写的内存语义当写一个volatile变量时JMM会把该线程对应的本地内存中的共享变量值刷新到主内存(注意是所有的共享变量不光是volatile变量)当读一个volatile变量时JMM会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量(注意这里也是所有的共享变量)关于线程如何确定要将共享变量的值刷新到内存以及为何要从内存读取最新的值涉及到cpu之间的通信、嗅探等这里不做展开。悟volatile变量的内存语义保证了在读volatile变量之前内存中所有的共享变量都是最新的也就是之前执行的的任意线程的写操作都对本次的读操作可见同样本次写操作都对之后任意线程执行的读操作可见。而且volatile的读操作和写操作都具有原子性。1. volatile读写操作对重排序的影响JMM的内存语义解决了内存可见性可能会引发的问题但是还有一种问题可能会产生那就是指令重排序的问题volatile a 0;int b 1;public void A (){b 2; // 1a 1; // 2}public void B() {int c 0;if (a 1) // 3c b; // 4}假如volatile不会对重排序有任何影响的话那么由于代码1和代码2两处没有数据依赖性所以二者是可以重排序的我们假设代码2在代码1之前被执行此时由于a是volatile变量所以将a 1 b 1刷新进入主内存如果这时候方法A所在的线程cpu时间片用完了轮到了方法B在另一个线程中执行由于a是volatile变量所以代码3处执行的时候会将b 1 a 1从主内存中读出此时代码4再执行的话c会变为1而不是预想的2(因为按照我们书写的顺序来看a1发生在b2之后)发生这种错误的原因在于volatile变量写操作与在其之前的代码发生了重排序使得刷新内存的时机提早了可能会漏掉我们写在volatile变量赋值操作之前的那些共享变量的修改。所以这就引出了volatile变量对指令重排序的第一个影响第二个操作是volatile写时不管第一个操作是什么都不能重排序。这个规则确保 volatile写之前的操作不会被编译器重排序到volatile写之后。换句话说以volatile写这行代码为分割线之前的对共享变量的各种读写操作的指令不管如何进行重排序都不可能跑到volatile写操作之后执行确保volatile写操作刷新内存里共享变量的值时程序员希望发生的变动都能够正确的刷新到内存中同理对应也有volatile变量对指令重排序的另一个影响第一个操作是volatile读时不管第二个操作是什么都不能重排序。这个规则确保 volatile读之后的操作不会被编译器重排序到volatile读之前。确保volatile读操作读取内存里的最新值是程序员希望读到的、操作的值另外还有一条影响第一个操作是volatile写第二个操作是volatile读时不能重排序三、Lock锁的内存语义Java中的锁的内存语义和volatile一模一样而ReentrantLock加锁和释放锁的原理就是通过操作一个volatile状态变量来实现。1. ReentrantLock公平锁加锁的实现ReentrantLock有自己的继承链但是真正开始加锁是从自己的tryAcquire方法protected final boolean tryAcquire(int acquires) {final Thread current Thread.currentThread();int c getState(); // 获取锁的开始首先读volatile变量stateif (c 0) {if (isFirst(current) compareAndSetState(0, acquires)) { // ------------- 代码 1------------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;}重点在代码1注意这里的条件中有一个CAS操作也就是说多个竞争锁的线程中可能都能够执行到这里但是只有一个能够使得该条件返回true其他都返回false。执行CAS返回true的线程通过setExclusiveOwnerThread进行独占式绑定。而CAS返回false的线程最终会直接从该加锁方法中返回false意味着加锁失败。2. ReentrantLock公平锁释放锁的实现ReentrantLock公平锁的释放最终的实现是在其父类中实现的开始释放锁是在tryRelease方法中protected final boolean tryRelease(int releases){int c getState() - releases;if (Thread.currentThread() ! getExclusiveOwnerThread())throw new IllegalMonitorStateException();boolean free false;if (c 0) {free true;setExclusiveOwnerThread(null);}setState(c); // 释放锁的最后写volatile变量state return free;}由于线程已经得到了锁所以释放锁的方法中没有任何CAS操作API的调用释放锁的逻辑是判断c的值如果c为0了说明要释放锁此时需要解除线程对该锁的绑定如果c没有变为0只是简单的更新state永远不要忘了state是一个volatile变量。四、final的内存语义五、再理解happen-before原则happen-before原则是JMM对程序员的一种保证即一个操作A happen-before另一个操作B意味着A的结果对B可见且A的执行顺序在B之前并不意味着Java具体实现必须要按照happen-before指定的顺序来执行如果重排序后执行结果与按照happen-before关系来执行的结果一致那么也是允许的也就是说JMM的happen-before只是保证了串行语义的顺序和正确同步的顺序。也就是说A happen-before B如果A与B之间有依赖关系、同步关系的话那么A确实在B之前执行如果A与B之间没有依赖、没有同步关系的话那么A与B之间的执行顺序是可以改变的但是对于程序员来说结果都一样没所谓所以认为A执行在B之前也是可以的。三、线程四、Java中的Lock使用Lock比使用synchronized有很多优点Lock更灵活当一个线程同时涉及到多个锁的时候使用synchronized就显得很麻烦了比如在获取B锁之后要释放A锁在获取C锁之后要放弃B锁Lock对加锁有更多的选择Lock支持非阻塞地获取锁、能被中断地获取锁(当获取到锁的线程被中断时中断异常将会被抛出同时释放锁)、超时获取锁Java中Lock中常见的API方法image队列同步器Java中的队列同步器AbstractQueuedSynchronizer是用来构建锁和其他同步组件的基础框架。它使用一个int成员变量表示同步状态并且提供了CAS方法通过内置的FIFO队列来完成资源获取线程的排队工作。Java中的锁和其他的同步组件一般都是在内部定义一个同步器的实现子类通过同步器定义的方法来管理同步状态。锁是面向程序员的而其内部同步器的实现是面向设计者的。同步器提供给同步组件的方法主要就是上文Java锁语义中提到的getStatesetStatecompareAndSetState三个方法。一、队列同步器的实现原理Java中队列同步器内部维护了一个双向的队列队列的作用就是将没有竞争到锁的线程包装成一个Node节点插入到队列中其中头结点代表持有锁的线程。当然有一些具体的信息都包括在Node节点中image而线程之所以表现为一种阻塞状态是因为获取不到锁的线程会陷入一个自旋的循环中不断地尝试获取锁而导致线程卡在lock()方法处具体细节下面再说。需要注意的是AQS中将竞争锁失败的线层包装成节点插入到队列的尾部是一个CAS操作这保证了队列插入顺序在多线程下的正确性。二、独占式同步状态获取与释放上面说了Lock的实现基本上是委托于内部AQS的子类以ReenTrantLock为例其内部有一系列Sync的内部类是AQS的具体实现类而ReentrantLock的lock方法内部调用了sync的acquire(int arg):public final void acquire(int arg) {if (!tryAcquire(arg) acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt();}其中的tryAcquire(arg)方法的实现在上文中展示过了tryAcquire方法是多个线程竞争锁发生的地方只有一个锁能够返回true并且独占锁其他的都会返回false。而其他的tryAcquire返回false的线程会调用acquireQueued实现将线程包装成双向队列的Node并加入的同步队列中。final boolean acquireQueued(final Node node, int arg) {boolean failed true;try {boolean interrupted false;for (;;) {final Node p node.predecessor();if (p head tryAcquire(arg)) {setHead(node);p.next null; // help GCfailed false;return interrupted;}if (shouldParkAfterFailedAcquire(p, node) parkAndCheckInterrupt())interrupted true;}} finally {if (failed)cancelAcquire(node);}}重点关注方法内部的for循环通过这个循环我们知道只有头结点的后继节点会在自旋中调用tryAcquire方法尝试获取锁而其他的后继节点只是在空自旋然后当头结点代表的线程释放锁之后将其移除双向队列的地方在后继节点代替它成为头结点的地方看到了将被阻塞的节点加入到队列中的操作接下来该看看是如何把一个阻塞的线程包装成双向链表的节点的private Node addWaiter(Node mode) {Node node new Node(Thread.currentThread(), mode);// Try the fast path of enq; backup to full enq on failureNode pred tail;if (pred ! null) {node.prev pred;if (compareAndSetTail(pred, node)) {pred.next node;return node;}}enq(node);return node;}对于独占式获取锁的过程该方法传递的参数是Node.EXCLUSIVE代表一个正阻塞在独占状态下的节点。该方法实现的前半部分负责调用CAS方法将该节点加入到双向队列的尾部而最后有调用了一次enq(Node)方法private Node enq(final Node node) {for (;;) {Node t tail;if (t null) { // Must initializeif (compareAndSetHead(new Node()))tail head;} else {node.prev t;if (compareAndSetTail(t, node)) {t.next node;return t;}}}}Q:这里点疑惑好像又加入了一次尾部是不是有点重复了小结以ReentrantLock为例独占式锁的加锁流程ReentrantLock的lock方法的实现委托给了ReentrantLock内部的AQS的实现类Sync的acquire(int arg)方法而Sync并没有重写该方法acquire的具体实现在抽象父类AbstractQueuedSynchronizeracquire方法会调用tryAcquire方法尝试获取锁这里是发生多个线程竞争锁的地方其中只有一个线程能够通过CAS方法获取到锁返回true竞争失败的线程都会返回false那些竞争失败的线程首先会被addWaiter方法包装成一个双向队列的节点并且加入到双向队列的尾部之后会在acquireQueued方法进行自旋操作但是只有头结点的后继节点才会调用tryAcquire方法尝试获取锁其他的后继节点只会空自旋
