Java锁机制

最新推荐文章于 2024-08-07 16:33:13 发布
最新推荐文章于 2024-08-07 16:33:13 发布
阅读量1.7k 收藏 90
点赞数 12
分类专栏： Java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ThreeAspects/article/details/104125830
版权

目录

公平锁/非公平锁

  公平锁指多个线程按照申请锁的顺序来获取锁。非公平锁指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。

可重入锁

  可重入锁指的是可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁（前提得是同一个对象或者class），这样的锁就叫做可重入锁。ReentrantLock和synchronized都是可重入锁。可重入锁的意义便在于防止死锁。
  实现原理是通过为每个锁关联一个请求计数器和一个占有它的线程。当计数为0时，认为锁是未被占有的；线程请求一个未被占有的锁时，JVM将记录锁的占有者，并且将请求计数器置为1 。如果同一个线程再次请求这个锁，计数将递增；每次占用线程退出同步块，计数器值将递减。直到计数器为0,锁被释放。

用synchronized实现的例子
public class ReentrantTest implements Runnable {

    public synchronized void get() {
        System.out.println(Thread.currentThread().getName());
        set();
    }

    public synchronized void set() {
        System.out.println(Thread.currentThread().getName());
    }

    public void run() {
        get();
    }

    public static void main(String[] args) {
        ReentrantTest rt = new ReentrantTest();
        for(;;){
            new Thread(rt).start();
        }
    }
}
set()和get()同时输出了线程名称，
表明即使递归使用synchronized也没有发生死锁，证明其是可重入的。


ReentrantLock中可重入锁实现：
ReentrantLock 和 synchronized 不一样，需要手动释放锁，
所以使用 ReentrantLock的时候一定要手动释放锁，并且加锁次数和释放次数要一样
ReentrantLock使用示例
class LockX {
    private final Lock LOCK = new ReentrantLock(); // non-fair lock
    public void lockMethod() {
        LOCK.lock();
        try {
            doBiz();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            LOCK.unlock();
        }
    }
    public void doBiz() { 
    }
}
你需要注意的是你应该总是在try块中执行你的业务代码，然后在finally中unlock掉。


ReentrantReadWriteLock使用示例
abstract class CachedData {
    Object data;
    volatile boolean cacheValid;
    final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    void processCachedData() {
      rwl.readLock().lock();
      if (!cacheValid) {
        // Must release read lock before acquiring write lock
        rwl.readLock().unlock();
        rwl.writeLock().lock();
        try {
          // Recheck state because another thread might have
          // acquired write lock and changed state before we did.
          if (!cacheValid) {
            data = loadData();
            cacheValid = true;
          }
          // Downgrade by acquiring read lock before releasing write lock
          rwl.readLock().lock();
        } finally {
          rwl.writeLock().unlock(); // Unlock write, still hold read
        }
      }
      try {
        consumeData(data);
      } finally {
        rwl.readLock().unlock();
      }
    }
    abstract Object loadData();
    abstract void consumeData(Object data);
  }
别忘了在lock之后要unlock，否则如果一个写锁被获取之后没有释放的话，
就不可能有锁获得锁了除非它自己本身。通用的做法是在try 块中进行业务处理，
然后在finally中释放锁。Lock接口的使用相比于synchronized的使用要复杂很多，
所以在大部分情况下，你应该使用synchronized来做并发控制，
而不是Lock，但是如果想要做更加灵活的锁控制，
你就可以选择使用Lock接口的具体实现类来应用，或者继承AQS来实现自己的同步器。

不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生死锁。有一个经典的例子，使用自旋锁来模拟一个不可重入锁，代码如下：

import java.util.concurrent.atomic.AtomicReference;

public class UnreentrantLock {

    private AtomicReference<Thread> owner = new AtomicReference<Thread>();

    public void lock() {
        Thread current = Thread.currentThread();
        //这句是很经典的“自旋”语法，AtomicInteger中也有
        for (;;) {
            if (owner.compareAndSet(null, current)) {
                return;
            }
        }
    }

    public void unlock() {
        Thread current = Thread.currentThread();
        owner.compareAndSet(current, null);
    }
}

代码也比较简单，使用原子引用来存放线程，同一线程两次调用lock()方法，如果不执行unlock()释放锁的话，第二次调用自旋的时候就会产生死锁，这个锁就不是可重入的，而实际上同一个线程不必每次都去释放锁再来获取锁，这样的调度切换是很耗资源的。稍微改一下，把它变成一个可重入锁：

import java.util.concurrent.atomic.AtomicReference;

public class UnreentrantLock {

    private AtomicReference<Thread> owner = new AtomicReference<Thread>();
    private int state = 0;

    public void lock() {
        Thread current = Thread.currentThread();
        if (current == owner.get()) {
            state++;
            return;
        }
        //这句是很经典的“自旋”式语法，AtomicInteger中也有
        for (;;) {
            if (owner.compareAndSet(null, current)) {
                return;
            }
        }
    }

    public void unlock() {
        Thread current = Thread.currentThread();
        if (current == owner.get()) {
            if (state != 0) {
                state--;
            } else {
                owner.compareAndSet(current, null);
            }
        }
    }
}

在执行每次操作之前，判断当前锁持有者是否是当前对象，采用state计数，不用每次去释放锁。在AQS中维护了一个private volatile int state来计数重入次数，避免了频繁的持有释放操作，这样既提升了效率，又避免了死锁。

独享锁/共享锁

独享锁是指该锁一次只能被一个线程所持有。
共享锁是指该锁可被多个线程所持有。

互斥锁/读写锁

上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。

乐观锁/悲观锁

  乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。
  悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。
  乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。
  悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。
  悲观锁在Java中的使用，就是利用各种锁。乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。重量级锁是悲观锁的一种，自旋锁、轻量级锁与偏向锁属于乐观锁

分段锁

  分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。
  以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7与JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock)。
  当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。
  分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。

偏向锁/轻量级锁/重量级锁

  这三种锁是指锁的状态，并且是针对Synchronized。在Java 5通过引入锁升级的机制来实现高效Synchronized。这三种锁的状态是通过对象监视器在对象头中的字段来表明的。偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
  偏向锁的适用场景：始终只有一个线程在执行同步块，在它没有执行完释放锁之前，没有其它线程去执行同步块，在锁无竞争的情况下使用，一旦有了竞争就升级为轻量级锁，升级为轻量级锁的时候需要撤销偏向锁，撤销偏向锁的时候会导致stop the word操作；
在有锁的竞争时，偏向锁会多做很多额外操作，尤其是撤销偏向所的时候会导致进入安全点，安全点会导致stw，导致性能下降，这种情况下应当禁用；
  轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。
  重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。

自旋锁

  在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。
  自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
  自旋锁尽可能的减少线程的阻塞，适用于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗。
  但是如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用cpu做无用功，同时有大量线程在竞争一个锁，会导致获取锁的时间很长，线程自旋的消耗大于线程阻塞挂起操作的消耗，其它需要cpu的线程又不能获取到cpu，造成cpu的浪费。
———————————————————————————————————————

Java锁机制可归为Sychornized锁和Lock锁两类。
  Synchronized是基于JVM来保证数据同步的，底层使用指令码方式来控制锁的，映射成字节码指令就是增加来两个指令：monitorenter和monitorexit。当线程执行遇到monitorenter指令时会尝试获取内置锁，如果获取锁则锁计数器+1，如果没有获取锁则阻塞；当遇到monitorexit指令时锁计数器-1，如果计数器为0则释放锁。
  Lock底层是CAS乐观锁，是在硬件层面，通过特殊的CPU指令实现数据同步的，依赖AbstractQueuedSynchronizer类，把所有的请求线程构成一个CLH队列。而对该队列的操作均通过Lock-Free（CAS）操作。

Synchronized和Lock比较

  • Synchronized是关键字，内置语言实现，Lock是接口

  • Synchronized在线程发生异常时会自动释放锁，因此不会发生异常死锁。Lock异常时不会自动释放锁，所以需要在finally中实现释放锁

  • Lock是可以中断锁，Synchronized是非中断锁，必须等待线程执行完成释放锁

  • synchronized是非公平锁，Lock可以设置是否公平锁，默认是非公平锁

  • Lock的实现类ReentrantReadWriteLock提供了readLock()和writeLock()用来获取读锁和写锁的两个方法，这样多个线程可以进行同时读操作

  • Synchronized是一个非公平、悲观、独享、互斥、可重入的重量级锁

  • ReentrantLock是一个默认非公平但可实现公平的、悲观、独享、互斥、可重入、重量级锁

  • ReentrantReadWriteLocK是一个默认非公平但可实现公平的、悲观、写独享、读共享、读写、可重入、重量级锁

Synchronized

  在JDK1.5之前使用synchronized关键字保证同步，它可以把任意一个非NULL的对象当作锁。

  • 作用于方法时，锁住的是对象的实例(this)
  • 当作用于静态方法时，锁住的是Class实例，又因为Class的相关数据存储在永久带PermGen（jdk1.8则是metaspace），永久带是全局共享的，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程
  • synchronized作用于一个对象实例时，锁住的是所有以该对象为锁的代码块

Synchronized的实现如下图所示：
在这里插入图片描述
它有多个队列，当多个线程一起访问某个对象监视器的时候，对象监视器会将这些线程存储在不同的容器中。

  1. Contention List：竞争队列，所有请求锁的线程首先被放在这个竞争队列中
  2. Entry List：Contention List中那些有资格成为候选资源的线程被移动到Entry List中
  3. Wait Set：哪些调用wait方法被阻塞的线程被放置在这里
  4. OnDeck：任意时刻，最多只有一个线程正在竞争锁资源，该线程被成为OnDeck
  5. Owner：当前已经获取到所资源的线程被称为Owner
  6. !Owner：当前释放锁的线程

  ContentionList并不是真正意义上的一个队列，仅仅是一个虚拟队列。它只有Node以及对应的Next指针构成，并没有Queue的数据结构。每次新加入Node会在队头进行，通过CAS改变第一个节点为新增节点，同时新增阶段的next指向后续节点，而取数据都在队列尾部进行。
  JVM每次从队列的尾部取出一个数据用于锁竞争候选者（OnDeck），但是并发情况下，ContentionList会被大量的并发线程进行CAS访问，为了降低对尾部元素的竞争，JVM会将一部分线程移动到EntryList中作为候选竞争线程。Owner线程会在unlock时，将ContentionList中的部分线程迁移到EntryList中，并指定EntryList中的某个线程为OnDeck线程（一般是最先进去的那个线程）。Owner线程并不直接把锁传递给OnDeck线程，而是把锁竞争的权利交给OnDeck，OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大的提升系统的吞吐量，在JVM中，也把这种选择行为称之为“竞争切换”。
  OnDeck线程获取到锁资源后会变为Owner线程，而没有得到锁资源的仍然停留在EntryList中。如果Owner线程被wait方法阻塞，则转移到WaitSet队列中，直到某个时刻通过notify或者notifyAll唤醒，会重新进去EntryList中。
  处于ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，该阻塞是由操作系统来完成的（Linux内核下采用pthread_mutex_lock内核函数实现的）。该线程被阻塞后则进入内核调度状态，会导致系统在用户和内核之间进行来回切换，严重影响锁的性能。为了缓解上述性能问题，JVM引入了自旋锁(上边已经介绍过自旋锁)。原理非常简单，如果Owner线程能在很短时间内释放锁资源，那么哪些等待竞争锁的线程可以稍微等一等（自旋）而不是立即阻塞，当Owner线程释放锁后可立即获取锁，进而避免用户线程和内核的切换。但是Owner可能执行的时间会超过设定的阈值，争用线程在一定时间内还是获取不到锁，这是争用线程会停止自旋进入阻塞状态。基本思路就是先自旋等待一段时间看能否成功获取，如果不成功再执行阻塞，尽可能的减少阻塞的可能性，这对于占用锁时间比较短的代码块来说性能能大幅度的提升！
  Synchronized在线程进入ContentionList时，等待的线程会先尝试自旋获取锁，如果获取不到就进入ContentionList，这明显对于已经进入队列的线程是不公平的，还有一个不公平的事情就是自旋获取锁的线程还可能直接抢占OnDeck线程的锁资源。

Lock锁

  与synchronized不同的是，Lock锁是纯Java实现的，与底层的JVM无关。在java.util.concurrent.locks包中有很多Lock的实现类，常用的有ReentrantLock、ReentrantReadWriteLock，java的Lock接口的子类就是借助AQS来实现了lock和unlock。

ReentrantLock原理

  ReentrantLock主要利用CAS+AQS队列来实现，支持公平锁和非公平锁。ReentrantLock的基本实现可以概括为：先通过CAS尝试获取锁。如果此时已经有线程占据了锁，那就加入AQS队列并且被挂起。当锁被释放之后，排在CLH队列队首的线程会被唤醒，然后CAS再次尝试获取锁。此时，如果：
非公平锁：如果同时还有另一个线程进来尝试获取，那么有可能会让这个线程抢先获取
公平锁：如果同时还有另一个线程进来尝试获取，当它发现自己不是在队首的话，就会排到队尾，由队首的线程获取到锁

ReentrantLock默认构造器初始化为NonfairSync对象，由lock()和unlock的源码可以看到，它们分别调用了sync对象的lock()和release(1)方法。

NonfairSync
lock

final void lock() {
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

  首先用一个CAS操作，判断state是否是0，如果是0则把它置为1并且设置当前线程为该锁的独占线程，表示获取锁成功。当多个线程同时尝试占用同一个锁时，CAS操作只能保证一个线程操作成功，剩下的只能去排队啦。
  “非公平” 体现在这里，如果占用锁的线程刚释放锁，state置为0，而排队等待锁的线程还未唤醒时，新来的线程就直接抢占了该锁，那么就“插队”了。
  若当前有三个线程去竞争锁，假设线程A的CAS操作成功了，那么线程B和C则设置state失败，走到了else里面，调用acquire方法。
1.尝试去获取锁。如果尝试获取锁成功，方法直接返回。非公平锁tryAcquire的流程是：检查state字段，若为0，表示锁未被占用，那么尝试占用，若不为0，检查当前锁是否被自己占用，若被自己占用，则更新state字段，表示重入锁的次数。如果以上两点都没有成功，则获取锁失败，返回false。

2.入队。由于线程A已经占用了锁，所以B和C执行tryAcquire失败，并且入等待队列。如果线程A拿着锁不放，那么B和C就会被挂起。先看下入队的过程，进入到addWaiter(Node.EXCLUSIVE)方法：B、C线程同时尝试入队列，由于队列尚未初始化，tail==null，故至少会有一个线程会走到enq(node)。假设同时走到了enq(node)里，这里用到了自旋+CAS来实现非阻塞的原子操作。由于compareAndSetHead的实现使用了unsafe类提供的CAS操作，所以只有一个线程会创建head节点成功。假设线程B成功，之后B、C开始第二轮循环，此时tail已经不为空，两个线程都走到else里面。假设B线程compareAndSetTail成功，那么B就可以返回了，C由于入队失败还需要第三轮循环。最终所有线程都可以成功入队。

3.挂起。B和C相继执行acquireQueued(final Node node, int arg)。这个方法让已经入队的线程尝试获取锁，若失败则会被挂起。假设B和C在竞争锁的过程中A一直持有锁，那么它们的tryAcquire操作都会失败，因此会走到第2个if语句中。进入到shouldParkAfterFailedAcquire和parkAndCheckInterrupt方法：线程入队后能够挂起的前提是，它的前驱节点的状态为SIGNAL，所以shouldParkAfterFailedAcquire会先判断当前节点的前驱是否状态符合要求，若符合则返回true，然后调用parkAndCheckInterrupt，将自己挂起。如果不符合，再看前驱节点是否>0(CANCELLED)，若是那么向前遍历直到找到第一个符合要求的前驱，若不是则将前驱节点的状态设置为SIGNAL。整个流程中，如果前驱结点的状态不是SIGNAL，那么自己就不能安心挂起，需要去找个安心的挂起点，同时可以再尝试下看有没有机会去尝试竞争锁。

unlock()
  流程大致为先尝试释放锁，若释放成功，那么查看头结点的状态是否为SIGNAL，如果是则唤醒头结点的下个节点关联的线程，如果释放失败那么返回false表示解锁失败。看下tryRelease的执行过程：当前释放锁的线程若不持有锁，则抛出异常。若持有锁，计算释放后的state值是否为0，若为0表示锁已经被成功释放，并且则清空独占线程，最后更新state值，返回free。

FairSync
公平锁和非公平锁不同之处在于，公平锁在获取锁的时候，不会先去检查state状态，而是直接执行aqcuire(1)

ReentrantLock公平锁和非公平锁的区别
  tryAcquire是公平锁和非公平锁实现的区别。在公平锁中，每一次的tryAcquire都会检查CLH队列中是否仍有前驱的元素，如果仍然有那么继续等待，通过这种方式来保证先来先服务的原则；而非公平锁，首先是检查并设置锁的状态，这种方式会出现即使队列中有等待的线程，但是新的线程仍然会与排队线程中的对头线程竞争，所以新的线程可能会抢占已经在排队的线程的锁，这样就无法保证先来先服务，但是已经等待的线程们是仍然保证先来先服务的。

超时机制
  在ReetrantLock的tryLock(long timeout, TimeUnit unit) 提供了超时获取锁的功能。在指定的时间内如果获取到锁就返回true，获取不到则返回false。这种机制避免了线程无限期的等待锁释放。那么超时的功能是怎么实现的呢？还是用非公平锁为例：
  如果线程被中断了，那么直接抛出InterruptedException。如果未中断，先尝试获取锁，获取成功就直接返回，获取失败则进入doAcquireNanos。
  doAcquireNanos的流程简述为：线程先入等待队列，然后开始自旋，尝试获取锁，获取成功就返回，失败则在队列里找一个安全点把自己挂起直到超时时间过期。这里为什么还需要循环呢？因为当前线程节点的前驱状态可能不是SIGNAL，那么在当前这一轮循环中线程不会被挂起，然后更新超时时间，开始新一轮的尝试

Lock与synchronized 的区别

  1. synchronized是在JVM层面上实现的，Lock是用CAS来实现的，依赖于硬件。在资源竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降，但是ReetrantLock的性能能维持常态。JDK 1.6之后对synchronized进行了优化，两者性能差不多
  2. Synchronized是非公平锁，ReentrantLock是可以是公平也可以是非公平的
  3. Synchronized是不可以被中断的，而ReentrantLock中的lockInterruptibly()方法使得线程可以在被阻塞时响应中断，比如一个线程通过lockInterruptibly()方法获取到一个可重入锁，并执行一个长时间的任务，另一个线程通过interrupt()方法就可以立刻打断线程的执行，来获取持有的那个可重入锁
  4. 在发生异常时Synchronized会自动释放锁，而ReentrantLock需要开发者在finally块中显示释放锁
  5. Synchronized在特定的情况下对于已经在等待的线程是后来的线程先获得锁，而ReentrantLock对于已经在等待的线程一定是先来的线程先获得锁
K. Bob
关注
专栏目录
java锁机制，LOCK的实现类
浮生一梦
07-06 9121
1.synchronized --把代码块声明为 synchronized，有两个重要后果，通常是指该代码具有 原子性（atomicity）和 可见性（visibility）。 1.1 原子性 --原子性意味着个时刻，只有一个线程能够执行一段代码，这段代码通过一个monitor object保护。从而防止多个线程在更新共享状态时相互冲突。 1.2 可见性 --可见性则更为微妙，它要对付内
Java synchronized同步机制
晨风茶馆
12-13 2591
众所周知，在Java多线程编程中，一个非常重要的方面就是线程的同步问题。关于线程的同步，一般有以下解决方法：1. 在需要同步的方法的方法签名中加入synchronized关键字。2. 使用synchronized块对需要进行同步的代码段进行同步。3. 使用JDK 5中提供的java.util.concurrent.lock包中的Lock对象。另外，为了解决多个线程对同一变量进行访问时可能发生的安全性问题，我们不仅可以采用同步机制，更可以通过JDK 1.2中加入的ThreadLocal来保证更好的并发性。本篇
关于Java锁的描述及场景使用
最新发布
qq_40549814的博客
08-07 788
synchronized、ReentrantLock、ReentrantReadWriteLock、StampedLock、Semaphore、CountDownLatch、CyclicBarrier选择合适的锁机制可以确保线程安全，并提高应用程序的性能和可维护性。
JAVA锁机制
JAVA老菜鸟的博客
01-25 2579
synchronized和Lock均为可重入锁。即可为该对象多次加锁，通过锁标志+1进行操作；当所标志为0时，释放所。重入锁目的是为防止死锁发生。 synchronized：基于系统内核实现线程等待（通过linux系统pthread_mutex_lock命令进行等待）。         a、将线程通过CAS操作放入ContentionList队列头部。         b、当Ow
java 锁机制
Meiko记录
10-19 264
Java多线程加锁机制，有两种： Synchronized 显式Lock 不得不唠叨几句： 在《Java核心技术卷 一》是先讲比较难的显式Lock，而再讲的是比较简单的Synchronized 而《Java并发编程实战》在前4章零散地讲解了Synchronized，将显式Lock放到了13章 其实都比较坑，如果能先系统讲了Synchronized锁机制，接着讲显式Lock锁机制，那就很容易理解了。也不需要跨那么多章节。 那么接下来我们就开始吧~ 一、synchro
java锁机制详解.pdf
09-30
Java锁机制是多线程编程中的关键概念，用于控制对共享资源的并发访问。在Java中，主要的锁机制包括`synchronized`关键字和`Lock`接口（如`ReentrantLock`）。下面将详细讲解这两种锁机制及其应用。 1. `...
Java锁机制详解.pdf
11-02
Java锁机制是Java多线程编程中的核心概念之一，其主要目的是确保在多线程环境下，多个线程能够安全地访问共享资源，避免数据不一致的问题。Java锁机制的发展历经了多个版本的改进，尤其是Java 5.0引入的显示锁...
Java锁机制Lock用法示例
08-27
Java锁机制Lock用法示例 Java锁机制Lock是Java并发编程中的一种同步机制，用于解决多线程安全问题。Lock机制是Java 1.5以后引入的显示锁机制，相比于传统的synchronized隐式锁机制，Lock机制提供了更灵活和高效的...
面向Java锁机制的字节码自动重构框架.zip
10-16
Java锁机制是多线程编程中的关键组成部分，用于控制对共享资源的访问，确保并发环境下的数据一致性。本文将深入探讨Java锁机制，并基于提供的"面向Java锁机制的字节码自动重构框架"来讨论其背后的原理和应用。 在...
Java 锁机制
GuuInBelieve的博客
03-16 484
ReentrantLock 优点 可重入 可中断 可限时 公平锁 一般用法 public class Starter extends Thread { public static ReentrantLock lock = new ReentrantLock(); public static int i = 0; public Starter(St...
深入理解Java锁机制：并发控制的关键
Java的锁机制是其并发控制的关键组成部分，它确保多线程环境下对共享资源的有序访问。在Java中，锁通常由`synchronized`关键字或`java.util.concurrent`包中的更高级锁定机制实现。核心概念可以概括为以下几点： 1....
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值