Juc07_乐观锁和悲观锁、公平锁和非公平锁、递归锁(可重入锁)、死锁及排查、自旋锁

最新推荐文章于 2024-01-29 17:28:17 发布
最新推荐文章于 2024-01-29 17:28:17 发布
阅读量4.5k 收藏 8
点赞数 8
分类专栏： JUC并发编程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/TZ845195485/article/details/109398072
版权

文章目录

①. 乐观锁和悲观锁

  • ①. 悲观锁(synchronized关键字和Lock的实现类都是悲观锁)
  1. 什么是悲观锁？认为自己在使用数据的时候一定有别的线程来修改数据,因此在获取数据的时候会先加锁,确保数据不会被别的线程修改
  2. 适合写操作多的场景,先加锁可以保证写操作时数据正确(写操作包括增删改)、显式的锁定之后再操作同步资源
  3. synchronized关键字和Lock的实现类都是悲观锁
  • ②. 乐观锁
  1. 概念:乐观锁认为自己在使用数据时不会有别的线程修改数据,所以不会添加锁,只是在更新数据的时候去判断之前有没有别的线程更新了这个数据。如果这个数据没有被更新,当前线程将自己修改的数据成功写入。如果数据已经被其他线程更新,则根据不同的实现方式执行不同的操作
  2. 乐观锁在Java中通过使用无锁编程来实现，最常采用的时CAS算法,Java原子类中的递增操作就通过CAS自旋实现的
  3. 适合读操作多的场景,不加锁的特点能够使其读操作的性能大幅度提升
  4. 乐观锁一般有两种实现方式(采用版本号机制、CAS算法实现)
  • ③. 伪代码
	//悲观锁的调用方式
	public synchronized void m1(){
		//加锁后的业务逻辑
	}
	//保证多个线程使用的是同一个lock对象的前提下
	ReetrantLock lock=new ReentrantLock();
	public void m2(){
		lock.lock();
		try{
			//操作同步资源
		}finally{
			lock.unlock();
		}
	}
	//乐观锁的调用方式
	//保证多个线程使用的是同一个AtomicInteger
	private  AtomicInteger atomicIntege=new AtomicInteger();
	atomicIntege.incrementAndGet();

②. 公平锁和非公平锁

  • ①. 什么是公平锁和非公平锁
  1. 公平锁：是指多个线程按照申请锁的顺序来获取锁类似排队打饭先来后到
  2. 非公平锁：是指在多线程获取锁的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程优先获取到锁,在高并发的情况下,有可能造成优先级反转或者饥饿现象
    注意：synchronized 和 ReentrantLock 默认是非公平锁
  • ②. 排队抢票案例(公平出现锁饥饿)
    锁饥饿:我们使用5个线程买100张票,使用ReentrantLock默认是非公平锁,获取到的结果可能都是A线程在出售这100张票,会导致B、C、D、E线程发生锁饥饿(使用公平锁会有什么问题)
class Ticket {
    private int number = 50;

    private Lock lock = new ReentrantLock(true); //默认用的是非公平锁，分配的平均一点，=--》公平一点
    public void sale() {
        lock.lock();
        try {
            if(number > 0) {
                System.out.println(Thread.currentThread().getName()+"\t 卖出第: "+(number--)+"\t 还剩下: "+number);
            }
        }finally {
            lock.unlock();
        }
    }
    /*Object objectLock = new Object();

    public void sale(){
        synchronized (objectLock)
        {
            if(number > 0)
            {
                System.out.println(Thread.currentThread().getName()+"\t 卖出第: "+(number--)+"\t 还剩下: "+number);
            }
        }
    }*/
}
public class SaleTicketDemo {
    public static void main(String[] args) {
        Ticket ticket = new Ticket();
        new Thread(() -> { for (int i = 1; i <=55; i++) ticket.sale(); },"a").start();
        new Thread(() -> { for (int i = 1; i <=55; i++) ticket.sale(); },"b").start();
        new Thread(() -> { for (int i = 1; i <=55; i++) ticket.sale(); },"c").start();
        new Thread(() -> { for (int i = 1; i <=55; i++) ticket.sale(); },"d").start();
        new Thread(() -> { for (int i = 1; i <=55; i++) ticket.sale(); },"e").start();
    }
}
  • ③. 源码解读(ReentrantLock默认是非公平锁)
  1. 公平锁:排序排队公平锁,就是判断同步队列是否还有先驱节点的存在(我前面还有人吗?),如果没有先驱节点才能获锁
  2. 先占先得非公平锁,是不管这个事的,只要能抢获到同步状态就可以
  3. ReentrantLock默认是非公平锁,公平锁要多一个方法,所以非公平锁的性能更好(aqs源码)
    在这里插入图片描述
  • ④. 为什么会有公平锁、非公平锁的设计?为什么默认非公平？面试题
  1. 恢复挂起的线程到真正锁的获取还是有时间差的,从开发人员来看这个时间微乎其微,但是从CPU的角度来看,这个时间存在的还是很明显的,所以非公平锁能更充分的利用CPU的时间片,尽量减少CPU空闲状态时间
  2. 使用多线程很重要的考量点是线程切换的开销,当采用非公平锁时,当一个线程请求锁获取同步状态,然后释放同步状态,因为不需要考虑是否还有前驱节点,所以刚释放锁的线程在此刻再次获取同步状态的概率就变得非常大了,所以就减少了线程的开销线程的开销
  • ⑤. 什么时候用公平？什么时候用非公平？面试题
    (如果为了更高的吞吐量,很显然非公平锁是比较合适的,因为节省很多线程切换时间,吞吐量自然就上去了。否则那就用公平锁,大家公平使用)

③. 可重入锁(又名递归锁)

  • ①. 什么是可重入锁？
  1. 可重入锁又名递归锁,是指在同一个线程在外层方法获取锁的时候,再进入该线程的内层方法会自动获取锁(前提,锁对象得是同一个对象),不会因为之前已经获取过还没有释放而阻塞
  2. 如果是1个有synchronized修饰得递归调用方法,程序第2次进入被自己阻塞了岂不是天大的笑话,出现了作茧自缚
  3. 所以Java中ReentrantLock和Synchronized都是可重入锁,可重入锁的一个优点是可在一定程度避免死锁

  • ②. 可重入锁这四个字分开解释
    可: 可以 | 重: 再次 | 入: 进入 | 锁: 同步锁 | 进入什么:进入同步域(即同步代码块、方法或显示锁锁定的代码)

  • ③. 代码验证synchronized和ReentrantLock是可重入锁

//synchronized 是可重入锁
class Phone{
    public synchronized void sendSms() throws Exception{
        System.out.println(Thread.currentThread().getName()+"\tsendSms");
        sendEmail();
    }
    public synchronized void sendEmail() throws Exception{
        System.out.println(Thread.currentThread().getName()+"\tsendEmail");
    }

}
/**
 * Description:
 *  可重入锁(也叫做递归锁)
 *  指的是同一先生外层函数获得锁后,内层敌对函数任然能获取该锁的代码
 *  在同一线程外外层方法获取锁的时候,在进入内层方法会自动获取锁
 *  *  也就是说,线程可以进入任何一个它已经标记的锁所同步的代码块
 *  **/
public class ReenterLockDemo {
    /**
     * t1 sendSms
     * t1 sendEmail
     * t2 sendSms
     * t2 sendEmail
     * @param args
     */
    public static void main(String[] args) {
        Phone phone = new Phone();
        new Thread(()->{
            try {
                phone.sendSms();
            } catch (Exception e) {
                e.printStackTrace();
            }
        },"t1").start();
        new Thread(()->{
            try {
                phone.sendSms();
            } catch (Exception e) {
                e.printStackTrace();
            }
        },"t2").start();
    }
}

//ReentrantLock 是可重入锁
	class Phone implements Runnable {
	    private Lock lock = new ReentrantLock();
	
	    @Override
	    public void run() {
	        get();
	    }
	
	    private void get() {
	        lock.lock();
	        try {
	            System.out.println(Thread.currentThread().getName() + "\tget");
	            set();
	        } finally {
	            lock.unlock();
	        }
	    }
	
	    private void set() {
	        lock.lock();
	        try {
	            System.out.println(Thread.currentThread().getName() + "\tset");
	        } finally {
	            lock.unlock();
	        }
	    }
	}
	
	/**
	 * Description:
	 * 可重入锁(也叫做递归锁)
	 * 指的是同一先生外层函数获得锁后,内层敌对函数任然能获取该锁的代码
	 * 在同一线程外外层方法获取锁的时候,在进入内层方法会自动获取锁
	 * <p>
	 * 也就是说,线程可以进入任何一个它已经标记的锁所同步的代码块
	 **/
	public class ReenterLockDemo {
	    /**
	     * Thread-0 get
	     * Thread-0 set
	     * Thread-1 get
	     * Thread-1 set
	     */
	    public static void main(String[] args) {
	        Phone phone = new Phone();
	        Thread t3 = new Thread(phone);
	        Thread t4 = new Thread(phone);
	        t3.start();
	        t4.start();
	
	    }
	}
  • ④. 可重入锁的种类
  1. 隐式锁(即synchronized关键字使用的锁)默认是可重入锁,在同步块、同步方法使用
    (在一个synchronized修饰的方法或者代码块的内部调用本类的其他synchronized修饰的方法或代码块时,是永远可以得到锁的)
  2. 显示锁(即Lock)也有ReentrantLock这样的可重入锁
    (lock和unlock一定要一 一匹配,如果少了或多了,都会坑到别的线程)
  • ⑤. Synchronized的重入的实现机理(为什么任何一个对象都可以成为一个锁)
  1. 每个锁对象拥有一个锁计数器和一个指向持有该锁的线程的指针
  2. 当执行monitorenter时,如果目标锁对象的计数器为零,那么说明它没有被其他线程所持有,Java虚拟机会将该锁对象的持有线程设置为当前线程,并且将计数器加1
  3. 在目标锁对象的计数器不为零的情况下,如果锁对象的持有线程时当前线程,那么Java虚拟机可以将其计数器加1,否则需要等待,直到持有线程释放该锁
  4. 当执行monitorexit,Java虚拟机则需将锁对象的计数器减1。计数器为零代表锁已经释放
    在这里插入图片描述

④. 死锁及排查

  • ①. 什么是死锁？
    死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去,如果资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁
    在这里插入图片描述
  • ②. 产生死锁的原因
  1. 系统资源不足
  2. 进程运行推进的顺序不合适
  3. 资源分配不当
  • ③. 代码展示
public class DeadLockDemo{

    static Object lockA = new Object();
    static Object lockB = new Object();
    public static void main(String[] args){
        Thread a = new Thread(() -> {
            synchronized (lockA) {
                System.out.println(Thread.currentThread().getName() + "\t" + " 自己持有A锁，期待获得B锁");

                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

                synchronized (lockB) {
                    System.out.println(Thread.currentThread().getName() + "\t 获得B锁成功");
                }
            }
        }, "a");
        a.start();

        new Thread(() -> {
            synchronized (lockB){
            
                System.out.println(Thread.currentThread().getName()+"\t"+" 自己持有B锁，期待获得A锁");

                try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { e.printStackTrace(); }

                synchronized (lockA){
                
                    System.out.println(Thread.currentThread().getName()+"\t 获得A锁成功");
                }
            }
        },"b").start();


    }
}
  • ④. 如何排除死锁方式一:纯命令
D:\studySoft\Idea201903\JavaSelfStudy>jps
10048 Launcher
6276 DeadLockDemo
6332 Jps
9356
D:\studySoft\Idea201903\JavaSelfStudy>jstack 6276 (最后面有一个发现了一个死锁)
2021-07-28 16:05:36
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode):

"DestroyJavaVM" #16 prio=5 os_prio=0 tid=0x0000000003592800 nid=0x830 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"b" #15 prio=5 os_prio=0 tid=0x00000000253d5000 nid=0x1ba8 waiting for monitor entry [0x0000000025c8e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.xiaozhi.juc.DeadLockDemo.lambda$main$1(DeadLockDemo.java:31)
        - waiting to lock <0x0000000741404050> (a java.lang.Object)
        - locked <0x0000000741404060> (a java.lang.Object)
        at com.xiaozhi.juc.DeadLockDemo$$Lambda$2/2101440631.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

"a" #14 prio=5 os_prio=0 tid=0x00000000253d3800 nid=0xad8 waiting for monitor entry [0x0000000025b8e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.xiaozhi.juc.DeadLockDemo.lambda$main$0(DeadLockDemo.java:20)
        - waiting to lock <0x0000000741404060> (a java.lang.Object)
        - locked <0x0000000741404050> (a java.lang.Object)
        at com.xiaozhi.juc.DeadLockDemo$$Lambda$1/1537358694.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

"Service Thread" #13 daemon prio=9 os_prio=0 tid=0x000000002357b800 nid=0x1630 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #12 daemon prio=9 os_prio=2 tid=0x00000000234f6000 nid=0x1fd4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #11 daemon prio=9 os_prio=2 tid=0x00000000234f3000 nid=0x5c0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #10 daemon prio=9 os_prio=2 tid=0x00000000234ed800 nid=0x1afc waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #9 daemon prio=9 os_prio=2 tid=0x00000000234eb800 nid=0x2ae0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Command Reader" #8 daemon prio=10 os_prio=0 tid=0x0000000023464800 nid=0xc50 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Event Helper Thread" #7 daemon prio=10 os_prio=0 tid=0x000000002345f800 nid=0x1b0c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Transport Listener: dt_socket" #6 daemon prio=10 os_prio=0 tid=0x0000000023451000 nid=0x2028 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000002343f800 nid=0x1ea0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x00000000233eb800 nid=0x10dc runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x00000000233d3000 nid=0xafc in Object.wait() [0x000000002472f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000741008e98> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x0000000741008e98> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000021d0d000 nid=0x28ec in Object.wait() [0x000000002462f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x0000000741006b40> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x0000000741006b40> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

JNI global references: 2504


Found one Java-level deadlock:
=============================
"b":
  waiting to lock monitor 0x0000000021d10b58 (object 0x0000000741404050, a java.lang.Object),
  which is held by "a"
"a":
  waiting to lock monitor 0x0000000021d13498 (object 0x0000000741404060, a java.lang.Object),
  which is held by "b"

Java stack information for the threads listed above:
===================================================
"b":
        at com.xiaozhi.juc.DeadLockDemo.lambda$main$1(DeadLockDemo.java:31)
        - waiting to lock <0x0000000741404050> (a java.lang.Object)
        - locked <0x0000000741404060> (a java.lang.Object)
        at com.xiaozhi.juc.DeadLockDemo$$Lambda$2/2101440631.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)
"a":
        at com.xiaozhi.juc.DeadLockDemo.lambda$main$0(DeadLockDemo.java:20)
        - waiting to lock <0x0000000741404060> (a java.lang.Object)
        - locked <0x0000000741404050> (a java.lang.Object)
        at com.xiaozhi.juc.DeadLockDemo$$Lambda$1/1537358694.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:745)

Found 1 deadlock.
  • ⑤. 如何排除死锁方式二:jconsole(输入cmd,输入jconsole,点击检测死锁按钮)
    在这里插入图片描述在这里插入图片描述
    在这里插入图片描述

⑥. 自旋锁

  • ①. 什么是自旋锁？
    (是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁,当线程发现锁被占用时，会不断循环判断锁的状态，直到获取。这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU)
    在这里插入图片描述

  • ②. 如何手写一个自选锁

//自旋锁
public class AtomicReferenceThreadDemo {
    static AtomicReference<Thread>atomicReference=new AtomicReference<>();
    static Thread thread;
    public static void lock(){
        thread=Thread.currentThread();
        System.out.println(Thread.currentThread().getName()+"\t"+"coming.....");
        while(!atomicReference.compareAndSet(null,thread)){

        }
    }
    public static void unlock(){
        System.out.println(Thread.currentThread().getName()+"\t"+"over.....");
        atomicReference.compareAndSet(thread,null);
    }
    public static void main(String[] args) {
        new Thread(()->{
            AtomicReferenceThreadDemo.lock();
            try { TimeUnit.SECONDS.sleep(3);  } catch (InterruptedException e) {e.printStackTrace();}
            AtomicReferenceThreadDemo.unlock();
        },"A").start();

        new Thread(()->{
            AtomicReferenceThreadDemo.lock();
            AtomicReferenceThreadDemo.unlock();
        },"B").start();
    }
}
  • ③. CAS缺点
  1. 循环时间长开销很大
  2. 引出来ABA问题(在CAS篇章将详细说明)

在这里插入图片描述

所得皆惊喜
关注
  • 8
    点赞
  • 踩
  • 8
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 7
    评论
专栏目录
线程调度、公平锁和非公平锁、乐观锁和悲观锁、锁优化、重入锁
Zhxin606a的博客
03-16 594
1. 线程调度 线程调度指的就是给线程分配使用处理器的过程。主要的调度方式有两种：协同式调度和抢占式调度。 1.1 协同式调度 线程完成自己的任务之后主动通知系统切换到另一个线程上。 优点： 实现简单，线程对于自己的切换是已知的，不存在线程同步的问题； 缺点： 如果一个线程一直阻塞占用处理器，则其他线程都会被阻塞。 1.2 抢占式调度 由系统来为线程分配使用处理器的时间片。 优...
乐观锁、悲观锁、公平锁、可重入锁
Seven
06-06 542
乐观锁 认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁； 在进行数据提交更新时，才会正式对数据冲突与否进行检测； 乐观锁并不会使用数据库提供的锁机制，一般在表中添加version字段或者使用业务状态来实现； 乐观锁直到提交时才锁定，所以不会产生任何死锁。 悲观锁 指对数据被外界修改保持保守态度，认为数据很容易就被其他线程修改； 在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态； 悲观锁的实现往往依靠数据库提供的锁机制。 公平锁
常见的锁策略详细讲解(悲观锁 vs 乐观锁，轻量锁 vs 重量锁，自旋锁 vs 互斥锁，公平锁 vs 非公平锁，读写锁等)
Shine0115的博客
01-02 1000
本篇文章详细讲解了各种锁策略，以及代码的演示，有需要的小伙伴请认真查阅！！！
Java中的21种锁
新技术革命
09-03 759
本篇主要内容如下： 本篇主要内容 本篇文章已收纳到我的Java在线文档、 Github 我的SpringCloud实战项目持续更新中 帮你总结好的锁： 序号锁名称应用1乐观锁CAS2悲观锁synchronized、vector、hashtable3自旋锁CAS4可重入锁synchronized、Reentrantlock、Lock5读写锁ReentrantReadWriteLock，CopyOnWriteArrayList、CopyOnWriteArraySet6公平锁Reentrant.
乐观锁,悲观锁,公平锁,非公平锁,死锁,可重入锁,同步锁,读写锁,表锁,行锁,间隙锁,排它锁,自旋锁
qq_21277357的博客
09-11 227
非公平锁:new ReentrantLock(false)或者不传参数,一个人吧活都干了,其他人都闲着,效率高。乐观锁：java.util.concurrent.atomic.*下面的类,保证了原子性,不需要加锁,效率高。公平锁:new ReentrantLock(true),多个人干活,效率低。synchronized和ReentrantLock都属于悲观锁;悲观锁：线程阻塞,效率低。
悲观锁、乐观锁、公平锁、非公平锁、独占锁、共享锁、可冲入锁和自旋锁你懂了吗？
Steve Rogers的博客
10-19 1526
悲观锁：悲观锁是指心态十分的悲观，认为每次去读数据时，别人都有可能会对数据进行修改，所以悲观锁每次读数据时都会对数据进行上锁操作，所以synchronized和ReentrantLock都是悲观锁，另外对于MySQL数据库，“SELECT * FROM xxx FOR UPDATE”，其实利用了MySQL的行锁，会对该行内容上锁，上锁期间别的线程无法进行操作，另外MySQL还有表锁。 乐观锁：乐观锁是指心态十分的乐观，认为每次去读数据时，别人都不会对数据进行修改，乐观锁不会加锁，因为加锁是一种十分影响并发性
详解递归锁，以及递归锁与其他同步机制的区别
qq_33471732的博客
12-02 1898
递归锁是一种多线程同步机制，用于解决线程在多次获取同一个锁时产生死锁的问题。在递归锁中，同一个线程可以多次获取同一个锁，而不会造成死锁。递归锁具有两个主要操作：上锁（lock）和解锁（unlock）。线程可以多次上锁，但必须相应地多次解锁才能完全释放该锁。只有当线程解锁次数与上锁次数相等时，其他线程才能获取该锁。当一个线程请求上锁时，如果锁是未上锁状态，则线程获取锁并将其状态设置为已上锁，并将上锁次数设置为1。如果同一个线程再次请求上锁，递归锁会检查当前线程是否已经持有该锁。
Java concurrency之公平锁(一)_动力节点Java学院整理
08-30
ReentrantLock是Java中实现可重入锁的类，它有两种模式：公平锁和非公平锁。在公平锁模式下，线程获取锁的顺序严格按照CLH队列的顺序进行。ReentrantLock的内部结构包含一个Sync对象，Sync是AQS的子类，进一步分为...
Java concurrency之锁_动力节点Java学院整理
08-30
- ReentrantLock：作为独占锁，ReentrantLock提供了公平和非公平两种模式，支持锁的可重入性，具备与`synchronized`相似的功能，但提供了更多的控制选项。 理解并熟练掌握这些锁机制，可以帮助开发者更好地设计和...
JUC最详细思维导图，一次了解读写锁，可重入锁，Cas原理，volatile 关键字原理
06-27
这与传统的非可重入锁形成对比，后者可能导致死锁。 CAS（Compare and Swap，比较并交换）是一种无锁算法，它是许多并发工具的基础，比如`AtomicInteger`、`AtomicLong`和`AtomicReference`。这些原子类使用硬件...
JUC相关知识和底层实现原理分析.jpg
09-02
JUC底层实现原理分析，结构多线程更加贯彻同步知识
JUC AQS的加解锁.pdf
02-25
本资源描述了Java并发常见的问题AQS的加锁解锁的过程
Java的乐观锁，悲观锁，读写锁，递归锁
最新发布
sdasdas12的博客
01-29 1184
我们都知道在 Java 中为了保证一些操作的安全性，就会涉及到使用锁，但是你对 Java 的锁了解的有多少呢？Java 都有哪些锁？以及他们是怎么实现的，今天了不起就来说说关于 Java 的锁。
python线程互斥锁递归锁死锁
weixin_30369087的博客
09-25 273
一、为什么有了GIL还要给线程加锁 先说一下GIL，所谓的GIL，也叫全局解释器锁，它限制了任何时候都只能有一个线程进入CPU进行计算，所以python所谓的多线程并不能真正的并行。 那为什么有了GIL还需要给线程加锁呢？不是直接一个线程处理完一个数据才轮到下一个线程进行吗？线程锁不是多此一举？ 解决这个问题，我们得更深入到底层看看代码是怎么在CPU上运行的。在这里引入一个概念：原子操作 ...
Java中关于乐观、悲观锁、死锁的常见问题
m0_66605858的博客
09-14 397
乐观锁通常是读锁，乐观锁认为读的过程中大概率不会写入，所以支持多线程，并发率高。当数据提交的时候通过一种机制来验证数据是否存在冲突。乐观锁中出现数据不一致，需要检测并重读。乐观锁通常是通过在表中增加一个版本(version)或时间戳(timestamp)来实现,悲观锁通常在读的过程中拒绝有写入，也就是写入必须等待。不支持多线程。乐观锁适用于读多写少的场景，可以省去频繁加锁、释放锁的开销，提高吞吐量在写比较多的场景下，乐观锁会因为版本不一致，不断重试更新，产生大量自旋，消耗 CPU，影响性能。
JUC并发编程系列详解篇十三（悲观锁VS乐观锁）
m0_46198325的博客
09-11 290
在java并发编程中，锁有很多种类，如下图所示：悲观锁乐观锁自旋锁适应性自旋锁无锁偏向锁轻量级锁重量级锁公平锁非公平锁可重入锁不可重入锁共享锁排他锁。
悲观锁、乐观锁、死锁
m0_72636465的博客
12-13 432
谈谈你对悲观锁、乐观锁以及死锁的理解？？？
什么是CAS机制？
热门推荐
qq_32998153的博客
03-12 9万+
我们先看一段代码： 启动两个线程，每个线程中让静态变量count循环累加100次。 最终输出的count结果一定是200吗？因为这段代码是非线程安全的，所以最终的自增结果很可能会小于200。我们再加上synchronized同步锁，再来看一下。 加了同步锁之后，count自增的操作变成了原子性操作，所以最终输出一定是count=200，代码实现了线程安全。虽然synchronized...
Juc_并发编程目录
所得皆惊喜
10-21 7万+
只有登上山顶,才能看到那边的风光 时刻磨刀，学习提升，才能不被淘汰 更新中 感谢周阳老师的付出,将大厂学院JUC全部公开,第一次接触周阳老师的课程那个时候在学校,记得那个时候接近毕业了,看的JVM,出去准备面试。接着陆陆续续看了老师的cloud、面试第一季、第二季等,收获很大,也让自己在这个知识点上有了更多的理解。谈谈看完老师JUC后需要注意的几个小问题: (1). 不需要预习,直接看视频劲量在课上就进行消化,建议自己也总结,加上自己的认知 (2). 从CompletableFeture到JVM、到后面的
juc的公平锁与非公平锁
10-17
JUC中的公平锁和非公平锁都是ReentrantLock类的实现。公平锁和非公平锁的区别在于获取锁的方式不同。 公平锁：线程获取锁的顺序是按照线程加锁的顺序来分配的，即先来先得的原则。当一个线程释放锁时，等待时间最长的线程将获得锁。 非公平锁：线程获取锁的顺序是随机的，不保证等待时间最长的线程能够优先获得锁。当一个线程释放锁时，任何一个等待锁的线程都有机会获得锁。 在实际应用中，如果对于线程获取锁的顺序有严格要求，可以使用公平锁；如果对于线程获取锁的顺序没有严格要求，可以使用非公平锁，因为非公平锁的吞吐量比公平锁高。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

所得皆惊喜

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值