Lock和synchronized，CAS简述及资料总结

最新推荐文章于 2024-03-02 10:29:56 发布
最新推荐文章于 2024-03-02 10:29:56 发布
阅读量765 收藏
点赞数
分类专栏： 锁 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_45216590/article/details/108361458
版权
本文介绍了Java并发编程中的AQS（AbstractQueuedSynchronizer）及其在ReentrantLock和synchronized中的应用。AQS基于FIFO双向队列，ReentrantLock分为公平锁和非公平锁。synchronized会经历无锁、偏向锁、轻量级锁到重量级锁的升级过程，涉及到自旋锁和CAS操作。文章还讨论了CAS的ABA问题和高竞争下的CPU开销问题。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

ReentranLock和Synchronized

AQS

参考资料：https://blog.youkuaiyun.com/qq_35190492/article/details/104691668
( AbstractQueuedSynchronizer 抽象队列同步器 ) 是java juc并发工具类的基础，即队列同步器。它是构建锁或者其他同步组件的基础框架（如ReentrantLock、ReentrantReadWriteLock、Semaphore等）

1. AQS基本的数据结构是FIFO双向队列，如下图

在这里插入图片描述
从图中可以看出来，AbstractQueuedSynchronizer内部维护了一个Node节点类和一个ConditionObject内部类。Node内部类是一个双向的FIFO队列，用来保存阻塞中的线程以及获取同步状态的线程，而ConditionObject对应的是Lock中的等待和通知机制
在这里插入图片描述

public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable {

    static final class Node {

        static final int CANCELLED =  1;    //当前节点被取消。

        static final int SIGNAL    = -1;    //表示当前节点的的后继节点将要或者已经被阻塞，在当前节点释放的时候需要unpark（唤醒）后继节点。

        static final int CONDITION = -2;    //表示当前节点在等待condition，即在condition队列中。

        static final int PROPAGATE = -3;    //表示releaseShared需要被传播给后续节点（仅在共享模式下使用）。

        //等待状态（默认0：无状态，表示当前节点在队列中等待获取锁。）
        volatile int waitStatus;

        volatile Node prev;

        volatile Node next;

        //当前节点代表的线程
        volatile Thread thread;

        Node nextWaiter;


        Node() {}

        Node(Node nextWaiter) {
            this.nextWaiter = nextWaiter;
            THREAD.set(this, Thread.currentThread());
        }

        Node(int waitStatus) {
            WAITSTATUS.set(this, waitStatus);
            THREAD.set(this, Thread.currentThread());
        }
    }


    private transient volatile Node head;

    private transient volatile Node tail;

    //独占变量state（通过CAS和volatile保证了线程安全问题）
    //state的值表示其状态：如果是0，那么当前还没有线程独占此变量；否在就是已经有线程独占了这个变量，也就是代表已经有线程获得了锁。大于1表示锁重入
    private volatile int state;


    private void setHead(Node node) {
        head = node;
        node.thread = null;    //防止内存泄漏
        node.prev = null;
    }

    public final void acquire(int arg) {
        //尝试获取锁（AQS在无竞争条件下，不会new出head和tail节点。），失败则自旋，阻塞当前线程，重新获取锁，直到获取锁成功
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))    //Node.EXCLUSIVE：标记指示节点在独占模式下等待
            selfInterrupt();
    }

    protected boolean tryAcquire(int arg) {
        throw new UnsupportedOperationException();
    }


    //ReentrantLock实现的公平锁
    static final class FairSync extends Sync {
        protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            //获取AQS中的state变量
            int c = getState();
            //值为0，那么当前独占性变量还未被线程占有
            if (c == 0) {
                //自旋获取锁（在没有其他等待时间更长的线程时：!hasQueuedPredecessors()）
                if (!hasQueuedPredecessors() &&
                    compareAndSetState(0, acquires)) {
                    //将本线程设置为独占性变量所有者线程
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            //如果该线程已经获取了锁，那么根据重入性原理，将state值进行加1，表示多次lock
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0)
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
    }


    //通过调用addWaiter函数，AQS将当前线程加入到了等待队列尾部，但是还没有阻塞当前线程的执行
    private Node addWaiter(Node mode) {
        Node node = new Node(mode);
        //自旋，直到插入成功
        for (;;) {
            Node oldTail = tail;
            if (oldTail != null) {
                node.setPrevRelaxed(oldTail);
                if (compareAndSetTail(oldTail, node)) {
                    oldTail.next = node;
                    return node;
                }
            } else {
                initializeSyncQueue();    //如果没有头尾节点，建立空节点，并赋值给头尾节点
            }
        }
    }

    //获取锁失败，则插入队尾，并自旋，阻塞线程，重新获取锁
    //队列中的线程获取锁的条件（公平锁）：上一个节点是头节点，并且成功tryAcquire(arg)
    final boolean acquireQueued(final Node node, int arg) {
        boolean interrupted = false;
        try {
            //如果当前线程成功获取锁，则将当前线程设置为头节点，否则一直自旋
            for (;;) {
                //返回上一个节点，如果为空，则抛出nullpointerexception
                final Node p = node.predecessor();
                //如果上一个节点是头结点，并且当前线程获取到锁，将当前结点设置为头结点，并返回
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node))    //将当前线程节点的prev指向有效节点
                    interrupted |= parkAndCheckInterrupt();    //阻塞线程
            }
        } catch (Throwable t) {
            cancelAcquire(node);
            if (interrupted)
                selfInterrupt();
            throw t;
        }
    }


    public final boolean release(int arg) {
        //尝试释放锁
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                //唤醒head节点的其他节点
                unparkSuccessor(h);
            return true;
        }
        return false;
    }


    protected boolean tryRelease(int arg) {
        throw new UnsupportedOperationException();
    }


    //ReentrantLock实现的公平锁
    abstract static class Sync extends AbstractQueuedSynchronizer {
        //释放独占性变量，就是将status的值减1（0：完全释放锁）
        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);
            return free;
        }
    }


    //释放锁后需要唤醒其他线程
    private void unparkSuccessor(Node node) {
        int ws = node.waitStatus;
        if (ws < 0)
            node.compareAndSetWaitStatus(ws, 0);
        Node s = node.next;
        //判断head节点的next节点是否为空或者是否是取消状态：如果是，则找其他节点。
        if (s == null || s.waitStatus > 0) {
            s = null;
            //从队列尾部向前遍历找到最前面的一个waitStatus<=0的节点
            for (Node p = tail; p != node && p != null; p = p.prev)
                if (p.waitStatus <= 0)
                    s = p;
        }
        if (s != null)
            //唤醒找到的节点线程
            LockSupport.unpark(s.thread);
    }
}

2. AQS获取锁–aquire方法流程图

在这里插入图片描述

ReentrantLock基于AQS的实现，可重入锁

abstract static class Sync extends AbstractQueuedSynchronizer{}//抽象类
static final class NonfairSync extends Sync{}//非公平锁继承Sync类
static final class FairSync extends Sync{}//公平锁继承Sync类

图解如下，注：reentrantLock默认是非公平锁
在这里插入图片描述

NonFairSync非公平锁–默认是非公平锁

非公平锁定义：如果有任意新的线程妄图获得锁，都是有很大概率直接获得锁（等待队列中的只有头部有机会去竞争，其他都处于等待唤醒）

static final class NonfairSync extends Sync {
        
        final void lock() {
        	//通过cas尝试获取锁，取锁成功则将
            if (compareAndSetState(0, 1))
            	//设置当前线程为独占锁的拥有者
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);
        }

        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
        //acquires 是1
	final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();//获取state值
            if (c == 0) {
				//如果当前没有线程占用锁 通过CAS更新state标志位
				//(这里也是非公平锁的一个原因 不判断前面是否有其它节点 直接CAS尝试拿锁)
                if (compareAndSetState(0, acquires)) {
					//将当前线程设置为独占锁的拥有者
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
			//如果state不为0 并且当前线程就是独占锁的拥有者（表示重入）
            else if (current == getExclusiveOwnerThread()) {
				//累加state
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
       }
       	//新节点入队方法
	private Node addWaiter(Node mode) {
        Node node = new Node(mode);

        for (;;) {//通过阻塞的方式将当前的node入队
            Node oldTail = tail;//获取尾结点
            if (oldTail != null) {
				//将新节点插入到队列尾部
                U.putObject(node, Node.PREV, oldTail);
                if (compareAndSetTail(oldTail, node)) {
                    oldTail.next = node;
                    return node;
                }
            } else {
				//队列为空 初始化队列
                initializeSyncQueue();
            }
        }
    }
}

FairSync公平锁

	final void lock() {
            acquire(1);
    }
	
	//acquire的实现与非公平锁相同，唯一区别是多了hasQueuedPredecessors()方法，即判断头结点后面一个结点是否为当前线程
	//看一下公平锁的tryAcquire
	protected final boolean tryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
				//与非公平锁不一致的地方在于 这里需要
				//判断当前线程前是否还有其他节点
				//如果有其它节点则需要到后面的阻塞排队逻辑
                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() {
        // The correctness of this depends on head being initialized
        // before tail and on head.next being accurate if the current
        // thread is first in queue.
        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());
    }

Synchronized----锁升级（非公平锁）

参考资料：https://www.cnblogs.com/myseries/p/12213997.html
锁实际上是加在对象上的，那么被加了锁的对象我们称之为锁对象，在java中，任何一个对象都能成为锁对象。
为了让大家更好着理解虚拟机是如何知道这个对象就是一个锁对象的，我们下面简单介绍一下java中一个对象的结构。
java对象在内存中的存储结构主要有一下三个部分：

  1. 对象头
  2. 实例数据
  3. 填充数据
    这里强调一下，对象头里的数据主要是一些运行时的数据。
    其简单的结构如下
    在这里插入图片描述
    在这里插入图片描述
LockObject lockObject = new LockObject();//随便创建一个对象
synchronized(lockObject){
    //代码
}

锁升级过程

参考资料：https://blog.youkuaiyun.com/qq_35190492/article/details/104691668
膨胀过程：无锁（锁对象初始化时）-> 偏向锁（有线程请求锁） -> 轻量级锁（多线程轻度竞争）-> 重量级锁（线程过多或长耗时操作，线程自旋过度消耗cpu）；
在这里插入图片描述

无锁

当创建一个对象LockObject时，该对象的部分Markword关键数据如下
在这里插入图片描述
从图中可以看出，锁的标志位是“01”即表明是偏向锁，状态是“0”，表示该对象还没有被加上偏向锁（“1”是表示被加上偏向锁）。 该对象被创建出来的那一刻，就有了偏向锁的标志位，这也说明了所有对象都是可偏向的，但所有对象的状态都为“0”，也同时说明所有被创建的对象的偏向锁并没有生效。

偏向锁

不过，当线程执行到临界区（critical section）时，此时会利用CAS(Compare and Swap)操作，将线程ID插入到Markword中，同时修改偏向锁的标志位。

所谓临界区（critical section）： 就是只允许一个线程进去执行操作的区域，即同步代码块。CAS是一个原子性操作

此时的Mark word的结构信息如下：
在这里插入图片描述
上图表明，已经有线程获取到该偏向锁，并将线程ID置入对象头部相应标志位中
　　偏向锁是jdk1.6引入的一项锁优化，其中的“偏”是偏心的偏。它的意思就是说，这个锁会偏向于第一个获得它的线程，在接下来的执行过程中，假如该锁没有被其他线程所获取，没有其他线程来竞争该锁，那么持有偏向锁的线程将永远不需要进行同步操作。
也就是说:
在此线程之后的执行过程中，如果再次进入或者退出同一段同步块代码，并不再需要去进行加锁或者解锁操作，而是会做以下的步骤：

  1. Load-and-test，也就是简单判断一下当前线程id是否与Markword当中的线程id是否一致.
  2. 如果一致，则说明此线程已经成功获得了锁，继续执行下面的代码.
  3. 如果不一致，则要检查一下对象是否还是可偏向，即“是否偏向锁”标志位的值。
  4. 如果还未偏向，则利用CAS操作来竞争锁，也即是第一次获取锁时的操作。

如果此对象已经偏向了，并且不是偏向自己，则说明存在了竞争。此时可能就要根据另外线程的情况，可能是重新偏向，也有可能是做偏向撤销，但大部分情况下就是升级成轻量级锁了。
　　可以看出，偏向锁是针对于一个线程而言的，线程获得锁之后就不会再有解锁等操作了，这样可以省略很多开销。假如有两个线程来竞争该锁话，那么偏向锁就失效了，进而升级成轻量级锁了。

锁撤销

由于偏向锁失效了，那么接下来就得把该锁撤销，锁撤销的开销花费还是挺大的，其大概的过程如下：

在一个安全点停止拥有锁的线程。
遍历线程栈，如果存在锁记录的话，需要修复锁记录和Markword，使其变成无锁状态。
唤醒当前线程，将当前锁升级成轻量级锁。
所以，如果某些同步代码块大多数情况下都是有两个及以上的线程竞争的话，那么偏向锁就会是一种累赘，对于这种情况，我们可以一开始就把偏向锁这个默认功能给关闭

轻量级锁

在这里插入图片描述
轻量级锁主要有两种

  1. 自旋锁
  2. 自适应自旋锁
自旋锁

所谓自旋，就是指当有另外一个线程来竞争锁时，这个线程会在原地循环等待，而不是把该线程给阻塞，直到那个获得锁的线程释放锁之后，这个线程就可以马上获得锁的。
自旋锁的一些问题
如果同步代码块执行的很慢，需要消耗大量的时间，那么这个时侯，其他线程在原地等待空消耗cpu，这会让人很难受。
本来一个线程把锁释放之后，当前线程是能够获得锁的，但是假如这个时候有好几个线程都在竞争这个锁的话，那么有可能当前线程会获取不到锁，还得原地等待继续空循环消耗cup，甚至有可能一直获取不到锁。
解决方法：
基于这个问题，必须给线程空循环设置一个次数，当线程超过了这个次数，继续使用自旋锁就不适合了，此时锁会再次膨胀，升级为重量级锁。
默认情况下，自旋的次数为10次，用户可以通过-XX:PreBlockSpin来进行更改。

自适应自旋锁

所谓自适应自旋锁：线程空循环等待的自旋次数并非是固定的，而是会动态着根据实际情况来改变自旋等待的次数。
其大概原理是这样的：
假如一个线程1刚刚成功获得一个锁，当它把锁释放了之后，线程2获得该锁，并且线程2在运行的过程中，此时线程1又想来获得该锁了，但线程2还没有释放该锁，所以线程1只能自旋等待，但是虚拟机认为，由于线程1刚刚获得过该锁，那么虚拟机觉得线程1这次自旋也是很有可能能够再次成功获得该锁的，所以会延长线程1自旋的次数。
另外，如果对于某一个锁，一个线程自旋之后，很少成功获得该锁，那么以后这个线程要获取该锁时，是有可能直接忽略掉自旋过程，直接升级为重量级锁的，以免空循环等待浪费资源。

轻量级锁也被称为非阻塞同步、乐观锁，因为这个过程并没有把线程阻塞挂起，而是让线程空循环等待，串行执行。

重量级锁

在这里插入图片描述
重量级锁是依赖对象内部的monitor锁来实现的，而monitor又依赖操作系统的MutexLock(互斥锁)来实现的，所以重量级锁也被成为互斥锁。
缺点：线程拿不到锁，就会挂起，等待锁释放。这个过程存在线程上下文切换

CAS乐观锁

乐观锁和悲观锁是两种思想：
悲观锁的实现方式是加锁，如java中Lock和synchronized，数据库mysql的排它锁。
乐观锁的实现方式主要两种：cas机制和版本号机制。故乐观锁是不加锁的。

CAS缺点

  1. ABA问题
  2. 高竞争下CPU开销问题，比如拿不到锁一直cas导致cpu开销大
  3. 功能限制，如cas只能保证单个变量的原子性，这意味着：（1）原子性不一定保证线程安全，如java和volatile配合保证线程安全；（2）当涉及多个变量时cas无能为力
Lock锁+CAS+与Synchronized比较
whiteBearClimb的博客
03-06 2170
在大学时代接触Synchronized后，做的实验就一直用它处理线程安全问题。但是我们都知道它都是块状的粒度，粗大粗大的毛孔，喷着厚重的气息，方法执行到同步块，性能抖三抖，加在方法上，就锁住了整个实例对象，静态方法上，还锁住了整个类，所有这个类的实例对象都不能避免。monitorenter和monitorexit监视器实现的同步，虎视眈眈地看着每一个蹑手蹑脚进来的线程。步步紧跟，直到执行完同步块释...
synchronized、Lock、volatile和CAS
binzai325的专栏
05-24 349
一、Java的内存模型JMM 在多处理器系统中，每个处理器有自己的高速缓存，而他们又共享同一块内存（下文成主存，main memory主要内存），当多个处理器运算都涉及到同一块内存区域的时候，就有可能发生缓存不一致的现象。 二、并发编程的3个基本概念1.原子性 定义： 即一个操作或者多个操作 要么全部执行并且执行的过程不会被任何因素打断，要么就都不执行。 原子性是拒绝多线程操作的，不论是多核还是单核，具有原子性的量，同一时刻只能有一个线程来对它进行操作。简而言之，在整个操作过...
面试必问之synchronized与Lock的区别及底层实现
爱码僧的博客
04-14 1万+
1、synchronized 是Java内置的关键字，使用后会自动释放锁， Lock是java.util.concurrent.Locks 包下的一个接口，必须要手动释放。特别是在发生异常时，需要在 finally 块中进行手动释放，否则会发生死锁行为 synchronized 代码清单 Lock 代码清单 2、Lock可响应中断，而synchronized 不能响应中断，并且Lo...
synchronized和Lock锁原理理解，CAS原理，锁升级策略
wang_yi_l的博客
08-14 1294
synchronized的原理 synchronized底层是通过对象内部的一个监视器锁（monitor）来实现的，是由一对monitorenter/monitorexit指令实现的。 什么是监视器锁？ 参考JVM对监视器锁的描述： monitorenter ： Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monit
synchronized、lock和cas理解
qq_41908272的博客
07-05 1192
这是小编我在看完ReentrantLock类之后对这几种可以实现锁的方式的理解，如果有什么理解的不对的，大家可以一起交流，共同进步。 synchronized synchronized这个关键子是java语言中可以用于实现锁的一种方式。这个关键字我们一般称为同步。这种加锁的方式也是我们平常经常用到的，就比如说小编前段时间碰到的一个问题，用户领取优惠券，这时发现一个用户在领取优惠券时都会发生多领的情...
互联网大厂高频面试题基本总结回顾（含笔试高频算法整理）
热门推荐
张彦峰的博客
04-03 176万+
1.自我介绍+项目介绍+项目细节/难点提问-------这个主要看个人的经历了，每个人都不一样 2.基础知识点考核---------还是可以去增强自己的，也是这次的主要的一些总结思路 3.算法题-----------一般都是LeetCode高频题，这个得在找工作之前的好好的练习(d对常见的高频题进行总结分析，见对应的链接提示)
java基础复习（八）：聊聊synchronized和Lock/AQS
qq_44793993的博客
06-27 1049
文章目录对线程安全问题的思考解构i++什么是同步和互斥线程通信为什么需要同步线程安全问题的解决方案加锁乐观锁与悲观锁无锁线程隔离threadLocal基本原理内存泄露问题Java内存模型原子/可见/有序问题的产生as-if-serial原则happens-before规则缓存一致性协议MESI缓存行总线嗅探CAS自旋锁（轻量级锁）无锁CAS存在的问题版本号CAS的内存语义synchronizedsynchronized的使用synchronize的内存语义jvm中的synchronizedsynchroni
Lock实现原理
weixin_41563161的博客
03-05 968
Lock实现原理 Lock完全用Java写成，在java这个层面是无关JVM实现的。 在java.util.concurrent.locks包中有很多Lock的实现类，常用的有ReentrantLock、ReadWriteLock（实现类ReentrantReadWriteLock），其实现都依赖java.u...
JVM高频面试基本问题与知识点整理
张彦峰的博客
01-16 85万+
JVM高频面试基本问题与知识点整理
Java高频面试基础问题与知识点整理
张彦峰的博客
11-04 171万+
Java高频面试知识点总结：覆盖高频基础知识考点+高频集合知识点深入分析+高频多线程与并发编程面试题汇总+其他扩展考察等。
Java锁 | synchronized、Lock与CAS详解
苏老师的博客
02-24 1387
Synchronized与Lock 1. 锁-简介 2. synchronized 3. Lock 悲观锁 4. CAS 自旋锁 4.1 ABA 问题
Lock锁之CAS
m0_56724799的博客
03-02 341
谈论锁就离不开CAS，CAS是compare and swap的缩写，从字面上理解就是比较并更新；主要是通过来保证操作的原子性简单来说：程序先要得到一个值A，这个值正常就是从我们要更新的内存位置得到的，进行CAS操作的时候，我们需要传入两个值，一个是A，一个是我们要修改的值B，此时才正式进入原子操作从内存位置V上取到存储的值，将值和预期值A进行比较，如果值和预期值A的结果相等，那么我们就把新值B更新到内存位置V上，如果不相等，那么就重复上述操作直到成功为止。
大白话聊聊synchronized、CAS底层原理、Lock锁和锁升级原理
qq_36752945的博客
03-11 1175
目录 1、乐观锁和悲观锁的概念 2、synchronized底层的原理 3. CAS的原理 4. 并发包下Lock锁和synchronized对比 5. 锁升级原理 大家好，我是四九城最豪横的小耳朵。 今天咱们来用大白话聊聊synchronized、CAS底层原...
Java进阶系列：锁：Synchronized、Lock、Volatile、CAS、Concurrent包
ljfirst的博客
08-16 332
未完待续。。。 探究Java 中的锁，其实主要讨论synchronized、lock、volatile的特性，以及具体到ReentrantLock、ReadWriteLock、CountDownLatch、CAS、AQS等类的用法上。 synchronized要从下面四个方面去理解 代码表现上 锁升级 锁在不同系统层面的实现 1、代码表现上 （1）Synchronized锁对象和同步方法时：只对该对象有效（对象锁：锁this或者锁其他对象）；具体见Synchronized方法锁、对象锁、类
Java CAS 和 synchronized 和 Lock
wwhhff11
05-20 2211
CAS 机制 适用场景：乐观认为并发不高，不需要阻塞，可以不上锁。 特点：不断比较更新，直到成功。 缺点：高并发cpu压力大；ABA问题。 ABA问题： CAS机制生效的前提是，取出内存中某时刻的数据，而在下时刻比较并替换。 如果在比较之前，数据发生了变化，例如：A-&gt;B-&gt;A，即A变为B然后又变化A，那么这个数据还是发生了变化，但是CAS还是会成功。 Java中CAS...
【Java并发编程】3.CAS、Lock、读写锁
sowhat
03-16 2397
CAS 什么是原子(Atom)操作： 多线程中的原子操作类似于数据库中的同时执行AB两个语句，要么同时执行成功，要么同时执行失败。 synchronize的不足： syn是基于阻塞的锁机制，颗粒度还是比较大 的。 如果被阻塞的线程优先级很高怎么办。 拿到锁的线程一直不释放锁怎么办。 如果出现大量竞争会消耗CPU，同时带来死锁或其他安全隐患。 用syn也可以实现原子操作不过不太合适，目前...
Java多线程与高并发四（Lock与CAS）
zab635590867的博客
11-03 1074
我们在《Java多线程与高并发一》中讲到怎样新建一个线程，用synchronized怎样给代码加锁，以及synchronized锁的优化升级。 在《Java多线程与高并发二》中，我们认识了Java的内存模型和计算机的内存架构，以及二者之间的不同，怎样弥补。 在《Java多线程与高并发三》中，我们我们认识了volatile关键字，以及其作用和深入原理。 《Java多线程与高并发四》给大家介绍L...
ConcurrentHashMap使用Node+CAS+synchronized实现线程安全
weixin_44893585的博客
02-29 4369
官网对ConcurrentHashMap的使用场景的介绍 //{Hashtable} is synchronized. If a //thread-safe implementation is not needed, it is recommended to use //{HashMap} in place of {@code Hashtable}. If a thread-safe //hi...
lock(CAS)和Sychronized的一些区别，以及lock怎么解决死锁lock(CAS)和Sychronized的一些区别，以及lock怎么解决死锁
qq_42180320的博客
02-18 514
lock(CAS)和Sychronized的一些区别，以及lock怎么解决死锁 A.区别 1.lock是更轻量级的，更灵活的，用户可以自定义配合多变的业务逻辑去加锁，但是Synchronized是块状粒度的，放在方法上，就锁住了整个实例对象，放在类上就锁住了这个类的所有实例对象 2.lock需要用户手动加锁释放锁，Synchronized不需要 3.lock默认是使用的非公平锁，Sychronized只有非公平锁 4.lock是一个类，Sychronized是一个关键字 5.lock不容易死锁，Sychro
java 简述乐观锁和悲观锁
最新发布
05-29
### Java 中乐观锁与悲观锁的概念及区别 #### 1. 悲观锁的定义与实现原理 悲观锁假设在多线程环境下，数据冲突的可能性较高，因此在访问共享资源时总是采取加锁的方式以确保数据一致性。悲观锁通过锁定资源来防止...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值