锁策略(乐观锁/悲观锁、自旋锁/互斥锁、读写锁、CAS算法、ABA问题)

于 2024-07-27 20:33:37 发布
阅读量691 收藏 16
点赞数 21
分类专栏： 多线程 文章标签： 算法 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Shine0115/article/details/140740664
版权

文章目录

Java中的悲观锁和乐观锁

Java中的悲观锁和乐观锁是一种锁的思想，并不是一种具体的锁，所以以下的内容，都是在讲解锁的思想，请读者不要和具体的锁产生混乱；

  • 悲观锁：总会认为冲突的概率会很大，当一个线程获取数据时，都会有其他的线程同时来修改这个数据，所以，当一个线程拿数据时，总会去加锁，这样，当别的线程想要对这个数据进行操作时，就会阻塞等待，换句话讲，就是共享资源在一个时刻间只能一个线程获取，其他线程阻塞等待，直到这个线程释放锁之后，其他线程才能够在尝试获取资源，所以，悲观锁更适合于多个线程对同一个资源进行修改的情况
  • 乐观锁：总会认为冲突的概率会很小，当一个线程获取数据的同时，认为其他的线程不会来对这个数据进行修改，所以，就没必要进行加锁，所以，正因为这个原因，乐观锁更适合于多个线程读取同一个资源的情况。虽然乐观锁去除了加锁的操作，但是，一旦发生冲突，重试的概率就会很大，所以，在冲突概率非常小，且加锁成本非常高时，才考虑使用乐观锁。

乐观锁常见的两种实现方式

  • 版本号机制
  • 基于时间戳
  • CAS 算法

版本号机制是要引入一个版本号属性version，来记录数据被修改的次数，

例如：

① 在数据库中，为每一条记录添加一个版本号字段version

② 当一个事务开始时，会先读取记录中当前的版本号，然后再执行对应的修改命令

③ 在事务提交更新之前，检查一下记录中的版本号是否还和当初读出的版本号一样，如果一样，则表示其他事没有进行修改，则更新成功，并将版本号+1

④ 如果版本号已经被修改了，则更新失败，事务进行回滚或者重试。

版本号机制

版本号机制是要引入一个版本号属性version，来记录数据被修改的次数，当数据被修改时，version+1，比如，线程A要更新数据的场景时，在获取这个这个数据的同时，会把version也获取到，当线程A对数据修改了以后，也会将version+1，然后，在提交这个更新后的数据时，如果刚才已经修改后的version值大于当前内存中的version值，更新数据，否则，重试更新操作，直到更新成功。

举个例子：假设有这样一种场景：当前，钱包中有100余额，线程A减了50，在线程A进行减50的过程中，线程B进行了减20的操作，请看下图：

基于时间戳

类似于版本号机制，但是用时间戳字段来跟踪记录的修改时间。

比如：

事务在读取记录时，同时获取到时间戳字段，并在提交事务时，检查记录的时间戳是是否与最初读取时的时间戳一致，如果一致，则更新成功，如果不同，则更新失败

CAS(compare and swap) 算法

比如，现在有一个内存M，有两个寄存器 A，B，假设CAS 相当于是一个函数，M，A，B是函数的三个参数，CAS(M，A，B)，如果 M 和 A 相同，就将 B 和 M 进行交换，说是交换，其实也就是一种赋值效果，因为，主要关心的是内存中 M 的值，而没人会关心 B 的值，同时整个操作返回 true，如果 M 和 A 不同，就什么事也不做，同时整个操作返回 false，

以上只是 CAS 的一个逻辑关系，CAS 并不是一个方法，一个CPU 指令完成了比较交换逻辑，这也就说明了CAS它是原子的，用来进一步替代了加锁操作。

所以，基于 CAS 实现线程安全的方式，也成为 “无锁编程”。

所以，CAS 的优点：避免了阻塞，降低了开销。缺点：只能使用于特定场景，不如加锁灵活。

同时呢，因为 CAS 本质上是一个 cpu 指令，后来被操作系统封装，提供成API，然后又被 JVM 封装，也提供成 API，供程序员们使用，如下图：

场景：两个线程对同一个变量count进行++：

public class Main {
    public static void main(String[] args) throws InterruptedException {

        AtomicInteger count = new AtomicInteger();

        Thread thread1 = new Thread(() -> {
            for(int i = 0; i < 100; i++) {

                count.getAndIncrement(); //count++;
                //count.incrementAndGet(); ++count
                //count.getAndDecrement(); count--
                //count.decrementAndGet(); --count;
            }
        });
         Thread thread2 = new Thread(() -> {
             for(int i = 0; i < 100; i++) {
                 count.getAndIncrement();
             }
         });
         thread1.start();
         thread2.start();
         thread1.join();
         thread2.join();
        System.out.println(count.get());
    }
}

CAS 适用场景

CAS 的适用场景

public class SpinLock {
    public AtomicInteger lock;
    public SpinLock() {
        lock = new AtomicInteger(0);
    }

    public void lock() {

        while(true) {
            int curValue = lock.get();//获取当前锁的值,也就相当于CAS(M, A, B) 中M的值
            if(curValue == 0) {// 表示此时锁还没有被获取
                if(lock.compareAndSet(0, 1)) {//尝试将锁的值从0原子的设置成1,也就是判断M和A得值是否相同
                    return; //成功获取到锁
                }
            }
        }

    }
    public void unlock() {
        lock.compareAndSet(1, 0);
    } 
}

ABA 问题

CAS 进行操作的关键是通过值“没有发生变化”来作为“没有其他线程穿插执行”的判定依据。也就是 CAS(M, A, B)，判断M有没有发生变化。但是，会出现 ABA 问题。

下面来演示一个例子解释ABA问题：

  1. 初始状态：有一个变量 V，其初始值为 A。
  2. 第一个线程（Thread A） 读取 V 的值（A），并准备将其更新为 B。
  3. 第二个线程（Thread B） 在 Thread A 读取 V 之后，但在更新之前，读取了 V 的值（A），并将其更新为 C。
  4. 第三个线程（Thread C） 在 Thread B 更新 V 之后，读取了 V 的值（C），并将其更新回 A。
  5. Thread A 继续执行，使用 CAS 操作试图将 V 的值从 A 更新为 B。由于 V 的值尚未被 Thread B 修改（仍为 A），CAS 操作成功执行。

在这个过程中，尽管 V 的值在 Thread A 首次读取和最终更新之间经历了变化（从 A 变为 C 再变回 A），CAS操作却未能检测到这一变化，因为在 CAS 操作执行时，V 的值看起来没有被修改。这就是 ABA 问题。这就好像我们买手机，买到的是一个二手的翻新机，看起来好像是一个新的，但是实际上是个二手的。

为了解决 ABA 问题，可以采用几种策略，最常见的是使用版本号或时间戳。在每次更新操作时，版本号递增，CAS 操作除了比较值外，还要比较版本号。只有当值和版本号都匹配时，更新才能成功。这样即使值被恢复到原始状态，由于版本号已经改变，CAS 操作能够识别出实际的变化

自旋锁 VS 互斥锁

互斥锁是一种独占锁，比如当线程A成功加锁后，此时，互斥锁就被线程A独占了，只要线程A没有释放手中的锁，线程B就会加锁失败，于是就会释放CPU给其他线程，既然线程B释放掉了CPU，自然线程B的加锁代码就会阻塞。

对于互斥锁这种加锁失败而阻塞的现象，是由操作系统内核实现的，当加锁失败后，这个线程就会进入睡眠状态，等到锁被释放以后，内核会在合适的时机唤醒线程，当这个线程成功获取到锁时，就可以继续执行。

所以，当加锁失败时，会从用户态变成内核态操作，让内核帮我们切换线程，此时就会产生一定的性能上的开销。

当两个线程属于同一个进程时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据和寄存器状态，线程的上下文等不共享的数据。

但是如果能够确定被锁住的代码很短，那么很可能上下文切换的时间比锁住的代码执行的时间还长，就不要用互斥锁了，应该使用自旋锁。

自旋锁是用户态完成加锁和解锁的操作，不会主动产生线程上下文切换，相比互斥锁来说，会更快一点，开销会小一点。

比如，在代码中使用while循环：

import java.util.concurrent.atomic.AtomicInteger;

public class SpinLock {
    private AtomicInteger lock = new AtomicInteger(0);

    public void lock() {
        int expectedValue = 0;
        while (!lock.compareAndSet(expectedValue, 1)) {
            expectedValue = 0; // 重置expectedValue，以准备下一次尝试
        }
    }

    public void unlock() {
        lock.set(0); // 释放锁，设置lock为0
    }

    public static void main(String[] args) {
        SpinLock spinLock = new SpinLock();
        Thread thread1 = new Thread(() -> {
            spinLock.lock();
            // 执行临界区代码
            System.out.println("Thread 1 is inside critical section.");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("Thread 1 is leaving critical section.");
            spinLock.unlock();
        });

        Thread thread2 = new Thread(() -> {
            spinLock.lock();
            // 执行临界区代码
            System.out.println("Thread 2 is inside critical section.");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("Thread 2 is leaving critical section.");
            spinLock.unlock();
        });

        thread1.start();
        thread2.start();
    }
}

读写锁

读写锁是由 读锁 和 写锁 两部分构成，如果只是读取共享资源的话，使用 读锁加锁，如果要修改共享资源的话，则用写锁加锁。

读写锁的工作原理就是：

当写锁没有被线程持有时，多个线程能够同时并发的持有读锁，因为读锁是用于读取共享资源的场景，所以，多个线程同时持有读锁也不会破坏共享资源的数据，这也就大大提高了共享资源的访问效率。

当写锁被线程持有后，那么，读操作的线程获取读锁时，就会被阻塞，写操作的线程获取写锁时也会被阻塞。

所以，写锁就是一种独占锁，任何时刻只能被一个线程拥有，读锁就是一种共享锁，可以让多个线程同时拥有。

读写锁的特性：

  • 读加锁 和 读加锁 之间不互斥
  • 写加锁 和 读加锁 之间互斥
  • 写加锁 和 写加锁 之间互斥

所以，读写锁在读操作多，写操作少的场景下，能发会出优势。

而且，读写锁也可以分为 读优先锁 和 写优先锁

读优先锁优先服务读线程，它的工作方式就是：比如，有一个 读线程 A 获取了读锁，写线程 B 在获取写锁时，就会进行阻塞，之后又有一个读线程 C 来获取读锁，此时读线程 C 能够成功的加锁，等到线程A和线程C都释放锁后，线程B才能够再获取到写锁。

但是，如果一直有读线程来获取读锁，那么，写线程就会一直进行阻塞，就造成了写线程饥饿的现象。

写优先锁就是优先服务写线程，比如，有一个读线程 A 获取了读锁，那么，写线程B在获取写锁时就会阻塞，之后又有一个读线程C来获取读锁，此时，线程C就会阻塞，等到 线程A释放锁后，线程B就可以获取 到写锁，而不是 线程C获取到读锁。

但是，写优先锁也会出现线程饥饿的情况，如果一直有写线程加锁，那么读线程就会被饿死。

在 Java 标准库中，提供了 ReentrantReadWriteLock 类，该类是基于读写锁实现的；

在这个类中，又实现了两个内部类，分别表示 读锁 和 写锁：

  • ReentrantReadWriteLock.ReadLock 类表示读锁，这个类提供了 lock() 方法进行加锁 和 unlock() 方法进行解锁
  • ReentrantReadWriteLock.WriteLock 类表示写锁，，这个类提供了 lock() 方法进行加锁 和 unlock() 方法进行解锁

代码示例：

示例一：两个线程都进行读操作。执行结果：可以同时获取锁

public class Main {
    //创建 ReentrantReadWriteLock实例，用于创建读锁和写锁实例
    private static ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
    //创建读锁实例
    private static ReentrantReadWriteLock.ReadLock readLock = reentrantReadWriteLock.readLock();
    //创建写锁实例
    private static ReentrantReadWriteLock.WriteLock writeLock = reentrantReadWriteLock.writeLock();
    //创建线程池
    private static ExecutorService threadPool = Executors.newCachedThreadPool();

    //获取的读锁方法
    public static void read() {
        //线程获取到读锁
        readLock.lock();
        System.out.println(Thread.currentThread().getName() + "获取读锁，开始执行");
        try {
            //睡眠3秒
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放读锁
            readLock.unlock();
            System.out.println(Thread.currentThread().getName() + "释放读锁，执行完成");
        }
    }
    //获取写锁的方法
    public static void write() {
        writeLock.lock();
        System.out.println(Thread.currentThread().getName() + "获取写锁，开始执行");
        try {
            //睡眠3秒
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放读锁
            writeLock.unlock();
            System.out.println(Thread.currentThread().getName() + "释放写锁，执行完成");
        }
    }
    public static void main(String[] args) {
        threadPool.submit(new Runnable() {
            @Override
            public void run() {
                read();
            }
        });
        threadPool.submit(new Runnable() {
            @Override
            public void run() {
                read();
            }
        });
    }
}

结论：由结果可以看到，多个线程在获取读锁时不会产生阻塞等待

在这里插入图片描述

示例二：一个线程进行读操作，一个线程进行写操作。执行结果：一个可以获取到锁，一个阻塞

public class Main {
    //创建 ReentrantReadWriteLock实例，用于创建读锁和写锁实例
    private static ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
    //创建读锁实例
    private static ReentrantReadWriteLock.ReadLock readLock = reentrantReadWriteLock.readLock();
    //创建写锁实例
    private static ReentrantReadWriteLock.WriteLock writeLock = reentrantReadWriteLock.writeLock();
    //创建线程池
    private static ExecutorService threadPool = Executors.newCachedThreadPool();

    //获取的读锁方法
    public static void read() {
        //线程获取到读锁
        readLock.lock();
        System.out.println(Thread.currentThread().getName() + "获取读锁，开始执行");
        try {
            //睡眠3秒
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放读锁
            readLock.unlock();
            System.out.println(Thread.currentThread().getName() + "释放读锁，执行完成");
        }
    }
    //获取写锁的方法
    public static void write() {
        writeLock.lock();
        System.out.println(Thread.currentThread().getName() + "获取写锁，开始执行");
        try {
            //睡眠3秒
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放读锁
            writeLock.unlock();
            System.out.println(Thread.currentThread().getName() + "释放写锁，执行完成");
        }
    }
    public static void main(String[] args) {
        threadPool.submit(new Runnable() {
            @Override
            public void run() {
                read();
            }
        });
        threadPool.submit(new Runnable() {
            @Override
            public void run() {
                write();
            }
        });
    }
}

结果：可以看出，获取读锁后时，写锁无法进行加锁，必须等读锁释放后才可以获取写锁

在这里插入图片描述

示例三：两个线程都进行写操作。执行结果：一个可以获取到锁，一个阻塞

public class Main {
    //创建 ReentrantReadWriteLock实例，用于创建读锁和写锁实例
    private static ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
    //创建读锁实例
    private static ReentrantReadWriteLock.ReadLock readLock = reentrantReadWriteLock.readLock();
    //创建写锁实例
    private static ReentrantReadWriteLock.WriteLock writeLock = reentrantReadWriteLock.writeLock();
    //创建线程池
    private static ExecutorService threadPool = Executors.newCachedThreadPool();

    //获取的读锁方法
    public static void read() {
        //线程获取到读锁
        readLock.lock();
        System.out.println(Thread.currentThread().getName() + "获取读锁，开始执行");
        try {
            //睡眠3秒
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放读锁
            readLock.unlock();
            System.out.println(Thread.currentThread().getName() + "释放读锁，执行完成");
        }
    }
    //获取写锁的方法
    public static void write() {
        writeLock.lock();
        System.out.println(Thread.currentThread().getName() + "获取写锁，开始执行");
        try {
            //睡眠3秒
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }finally {
            //释放读锁
            writeLock.unlock();
            System.out.println(Thread.currentThread().getName() + "释放写锁，执行完成");
        }
    }
    public static void main(String[] args) {
        threadPool.submit(new Runnable() {
            @Override
            public void run() {
                write();
            }
        });
        threadPool.submit(new Runnable() {
            @Override
            public void run() {
                write();
            }
        });
    }
}

结论：由执行结果可以看出，无法同时获取写锁

在这里插入图片描述

公平锁 VS 非公平锁

假设，现在有三个线程 A，B，C 轮流尝试获取同一把锁，此时，线程A获取到锁后，线程B 和 线程C依次阻塞等待，当线程A释放锁后，线程B获取锁，之后 线程C 再获取锁，这样按照“先来后到”的方式，来加锁，此时就是公平锁，反之，线程A释放锁喉，线程B 和 线程C 都有可能获取到锁，此时就是非公平锁

公平锁：按照“先来后到”的方式加锁，此时就是公平锁

非公平锁：不按照“先来后到”的方式，按照“抢占式”的方式，此时就是非公平锁。例如，synchronized 就是非公平锁

十二分精神~
关注
  • 21
    点赞
  • 踩
  • 16
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
互斥锁、读写锁、自旋锁、乐观锁、悲观锁、CAS
weixin_44677487的博客
09-06 477
CAS CAS是英文单词CompareAndSwap的缩写，中文意思是：比较并替换。CAS需要有3个操作数：内存地址V，旧的预期值A，即将要更新的目标值B。 CAS指令执行时，当且仅当内存地址V的值与预期值A相等时，将内存地址V的值修改为B，否则就什么都不做。整个比较并替换的操作是一个原子操作。例如：这个时候我们可以使用Java并发包原子操作类（Atomic开头） CAS（比较并交换）是CPU指令级的操作，只有一步原子操作，所以非常快 jdk5增加了并发包java.util.concurrent.*,其下
乐观锁悲观锁CAS锁自旋锁你了解吗？
ifwecande的博客
10-19 504
文章目录一，概念，使用场景1. 乐观锁2. 悲观锁3. 适用场景二，实现方式1. 版本号机制2. CAS锁3. 乐观锁的缺点1）ABA问题2）循环时间长开销大3）只能保证一个共享变量的原子操作 一，概念，使用场景 1. 乐观锁 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。 乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于write_condition机制，其实都是提
互斥锁，死锁，自旋锁，读写锁，乐观，悲观
qq_52563729的博客
07-17 538
死锁，互斥锁，自旋锁，读写锁
cas乐观锁 java_Java的CAS乐观锁原理解析
weixin_39983993的博客
02-27 103
CAS全称 Compare And Swap(比较与交换)，在不使用锁的情况下实现多线程之间的变量同步。属于硬件同步原语，处理器提供了基本内存操作的原子性保证。juc包中的原子类就是通过CAS来实现了乐观锁。CAS算法涉及到三个操作数：需要读写的内存值 V。进行比较的旧值A (期望操作前的值)要写入的新值 B。当且仅当 V 的值等于 A 时，CAS通过原子方式用新值B来更新V的值(“比较+更新”整...
乐观锁、悲观锁
yiliacheng
03-19 2578
文章目录1 悲观锁2 乐观锁2.1 CAS算法 (Compare and Swap)2.2 版本号机制 -- 可用于解决ABA问题3 c++ 中用过哪些锁？c++ 中有乐观锁吗？ 乐观锁对应于生活中乐观的人总是想着事情往好的方向发展； 悲观锁对应于生活中悲观的人总是想着事情往坏的方向发展。 1 悲观锁 总是假设最坏的情况，每次去拿数据的时候都认为会被修改，所以每次拿数据的时候都会上锁。这样别...
JUC第四讲：Java中的锁/CAS原理与案例分析
Jet_qi的博客
07-28 456
synchronized是Java的关键字，是Java的内置特性，在JVM层面实现了对临界资源的同步互斥访问synchronized特点synchronized则可以使用在变量、方法（静态方法，同步方法）、和类级别的修饰代码块时，减少了锁范围，耗时的代码放外面，可以异步调用synchronized各种加锁场景？1、作用于非静态方法，锁住的是对象实例（this），每一个对象实例有一个锁}}3、作用于Lock.class，锁住的是Lock的Class对象，也是全局只有一个}}...
【JUC】七、读写锁的演化 && 锁降级
llg___的博客
11-15 598
演化流程： 无锁 一> 独占锁 一> 读写锁 一> 邮戳锁无锁情况下，多线程抢夺资源，造成混乱且有数据安全问题独占锁下，两个写线程不能共享，这很合理，但如果全是读的线程，也排队读，就有待改进了读写锁：读写互斥，写写互斥，合理，但优化成了写写可以共享，解决了上面的改进点。读多写少的时候，就很合适。但读写锁也有缺点：写锁饥饿问题、锁降级针对读写锁的缺点，出现邮戳锁StampedLock（后面章节写）
Java并发编程(七)-各种锁、CAS、ABA、死锁
星光之子的博客
06-21 472
各种锁、CAS、ABA锁的作用锁分类乐观锁CAS（Compare And Swap）CAS的问题ABA自旋时间过长只能保证一个共享变量的原子操作悲观锁自旋锁自旋锁优缺点适应性自旋锁公平锁、非公平锁可重入锁共享锁、独占锁无锁、偏向锁、轻量级锁、重量级锁无锁偏向锁轻量级锁和重量级锁(理解)分段锁读写锁死锁锁优化 锁的作用 Java中的锁 主要用于 保障 多并发线程情况下 数据的一致性。在多线程编程中为了保障数据的一致性，通常需要在使用 对象 或者 方法 之前加锁，这时如果有其他线程也需要使用该对象或者该方法，则
Java 并发与多线程规范(4) 自旋锁是可重入的吗？CAS与自旋锁的关系,CAS的ABA问题,以及乐观锁,悲观锁,互斥锁,读写锁的整理
kkgbn的博客
07-19 2016
CASCAS,自旋锁跟compare and set有关系,但是并不是CAS就是自旋锁。我们看一段代码：/* 不同线程检测最大值 */ AtomicLong largest = new AtomicLong(); long obsvValue = 0; /* 错误的方式,此更新不是原子性的 */ largest.set(Math.max
自旋锁和互斥锁区别
07-18
线程同步(Thread Synchronization)是并行编程中非常重要的通讯手段，其中最典型的应用就是用Pthreads提供的锁机制(lock)来对多个线程之间共 享的临界区(Critical Section)进行保护(另一种常用的同步机制是barrier)。
深入讲解我们说的CAS自旋锁到底是什么
08-27
CAS（Compare and Swap）是实现自旋锁或乐观锁的核心操作，它的出现是为了解决原子操作的问题。在多线程环境下，原子操作是保证线程安全的重要手段。CAS操作的实现很简单，就是用一个预期的值和内存值进行比较，如果...
信号量、互斥体和自旋锁的区别
07-21
**信号量**、**互斥体**和**自旋锁**是操作系统中三种常用的同步机制，主要用于解决多线程或多进程环境中资源的并发访问问题。这三种机制虽然都用于实现同步控制，但在具体的应用场景和技术特性上存在显著差异。 ##...
p278 - p288 乐观锁和悲观锁
05-15
乐观锁和悲观锁 在编程世界中，锁是五花八门的，每种锁的加锁开销以及应用场景也可能会不同。如何用好锁，也是程序员的基本素养之一了。在高并发的场景下，如果选择了合适的锁，则会大大提高系统的性能，否则性能会...
用原子自旋读写锁代替互斥锁提高多线程访问公共资源效率
04-12
为了解决这个问题，原子自旋锁（Atomic Spin Lock）应运而生，它提供了一种更为高效的同步策略。 原子自旋锁是基于原子操作实现的一种锁机制。在自旋锁的状态下，线程并不像互斥锁那样被挂起，而是持续检查锁的状态...
代码随想录算法训练营第22天-leetcode-二叉树08：669. 修剪二叉搜索树；108.将有序数组转换为二叉搜索树；538.把二叉搜索树转换为累加树
weixin_65180740的博客
07-24 844
你可能需要改变树的根节点，所以结果应当返回修剪好的二叉搜索树的新的根节点。给出二叉 搜索 树的根节点，该树的节点值各不相同，请你将其转换为累加树（Greater Sum Tree），使每个节点 node 的新值等于原树中大于或等于 node.val 的值之和。题目要求，实际上是每个节点加上中序排列后面的那个节点，故而可以反向中序排序，即RNL，用prior记录前一个节点的值，加上前一个节点的值即可。左右子树也必须是二叉搜索树。后序遍历每个节点，对于在范围外的节点，考虑保留其左子树/右子树（只可能保留一个）
2.6基本算法之动态规划6045:开餐馆
最新发布
Andy_SCP001的博客
07-24 145
北大信息学院的同学小明毕业之后打算创业开餐馆.现在共有n 个地点可供选择。我们用一个整数序列m1, m2, ... mn 来表示他们的相对位置。由于地段关系,开餐馆的利润会有所不同。为了避免自己的餐馆的内部竞争,餐馆之间的距离必须大于k。//f[i]:从第1个位置到开第i个位置开餐馆能获得的最大利润。j++){//从j个地点到第i个地点开餐馆。//n个地点开一家店。//每个餐馆开的位置。//边界条件:只有一个地点,只开一家店。//n个地点开很多家店。
cf场+线性dp
xxx_jsu的博客
07-23 304
令a[1]=x[1]+1后我们可以让a[i+1]=a[i]+x[i]，但是这样的话数可能会比较小，所以我们可以累加a[i]，因为是mod所以只要不大于x[i+1]可以一直加下去。2.n>b-a>0这种情况我们还需要考虑到使用到的a，在此之前我们按照等差数列出售了(b-a)个，那么剩下n-(b-a)个我们则需要按照a来出售。采用双指针，一个指向a的头部，一个指向b的头部，两者开始进行匹配，若相同则b往下走一位，否则就终止。题目的第一问其实就是让我们求最长不上升子序列，第二问就是求有多少段最长不上升序列。
2766. 重新放置石块 Medium
珞米的博客
07-24 490
第 i = 0 步操作中，我们将位置 1 处的石块移到位置 2 处，有石块的位置为 [2,2,3,3]。第 i = 1 步操作中，我们将位置 3 处的石块移到位置 2 处，有石块的位置为 [2,2,2,2]。第 i = 0 步操作中，我们将位置 1 处的石块移到位置 2 处，位置 2,6,7,8 有石块。第 i = 1 步操作中，我们将位置 7 处的石块移到位置 9 处，位置 2,6,8,9 有石块。第 i = 2 步操作中，我们将位置 2 处的石块移到位置 5 处，位置 5,6,8,9 有石块。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值