一. 引言
1.1 背景介绍
随着多核处理器的普及和分布式计算的广泛应用，并发编程的重要性日益提升。尤其是在分布式系统中，多个线程和节点需要频繁地对共享资源进行并发访问，从而提升性能和吞吐量。然而，这也带来了线程安全、资源竞争等问题。为了应对这些问题，Java 提供了多种并发工具，其中 ReentrantReadWriteLock是一种专为高并发环境设计的锁机制，有效提升了读操作密集型场景下的系统性能。
1.2 YARN 中的并发挑战
YARN（Yet Another Resource Negotiator） 是 Hadoop 生态系统的核心组件之一，用于资源管理和任务调度。作为一个分布式资源调度框架，YARN 中的资源分配、任务状态更新等操作经常涉及高并发访问。在这些场景中，既要保证数据一致性，又要避免性能瓶颈。
YARN 中的一些典型并发需求包括：
资源状态的查询与更新：ResourceManager 需要维护整个集群的资源状态，包括节点的可用资源、任务的分配情况等。这些状态既需要频繁更新（写操作），又需要支持高频的查询（读操作）。
任务调度的并发控制：在任务调度过程中，调度器需要同时处理多个节点心跳、应用程序资源请求等，要求系统高效地协调多线程访问。
集群拓扑的元数据管理：YARN 集群中的节点状态、黑名单更新等操作也需要在多线程环境中高效完成。
ReentrantReadWriteLock 在这些场景中起到了重要作用，通过读写分离提升并发性能的同时，确保了系统的一致性和稳定性。
二. ReentrantReadWriteLock 的基本概念
2.1 什么是 ReentrantReadWriteLock？
ReentrantReadWriteLock 是 Java 并发库中提供的一种高级锁实现，位于 java.util.concurrent.locks 包中。它是一种支持读写分离的锁机制，设计目的是在“读多写少”的高并发场景下提升系统性能。与传统的互斥锁（如 ReentrantLock 或 synchronized）不同，ReentrantReadWriteLock 在支持锁的可重入下，允许多个线程同时读取共享资源（通过读锁），而写操作仍需独占访问（通过写锁）。
2.2 为什么需要 ReentrantReadWriteLock？
在多线程并发环境中，传统的互斥锁虽然能解决线程安全问题，但由于它只能允许一个线程访问共享资源，在读操作频繁的场景下，会带来性能瓶颈。ReentrantReadWriteLock 的核心价值在于分离读锁和写锁，实现“读并发、写独占”，从而优化性能：
1. 高效的读操作：允许多个线程同时读取资源，而不互相阻塞。
2. 安全的写操作：确保写操作的独占性，保证数据的一致性。
3. 灵活的锁控制：相比 synchronized，ReentrantReadWriteLock 提供了更多的可控功能（如公平锁、非公平锁选择，支持锁降级等）。
2.3 适用场景
ReentrantReadWriteLock 适用于以下场景：
1. 读多写少的高并发场景：
• 缓存系统：读取缓存的频率高于更新缓存的频率。
• 配置管理：多个线程同时读取配置信息，而修改配置的操作较少。
• 日志系统：多个线程同时读取日志数据，写日志的频率较低。
2. 需要灵活控制并发行为的场景：
• 当系统需要锁降级、尝试锁获取等高级功能时，ReentrantReadWriteLock 是一个理想选择。
3. 复杂的状态管理场景：
• 在分布式系统中，例如任务调度或资源管理系统，需要高频查询和少量更新操作的混合场景。
三. ReentrantReadWriteLock 的工作原理
3.1 内部结构与设计
ReentrantReadWriteLock 是基于 Java 并发框架的核心组件 AbstractQueuedSynchronizer (AQS) 实现的，其内部设计分为以下几个部分：
1. 读锁（ReadLock）：实现为共享锁，允许多个线程同时获取。
2. 写锁（WriteLock）：实现为独占锁，同一时刻只有一个线程可以持有写锁。
3. AQS 状态表示：通过一个 32 位整数来维护锁的状态，高 16 位表示读锁状态（即持有读锁的线程数）。低 16 位表示写锁状态（即持有写锁的线程的重入次数）。
3.1.1 独享锁与共享锁
ReentrantReadWriteLock的多个线程可同时持有读锁（共享锁），适用于并发读的场景。但写锁（排他锁）是独占的，当一个线程持有写锁时，其他线程无法获取写锁或读锁。其中，写锁与写锁互斥（单线程写）；写锁与读锁互斥（写操作阻止读操作）；读锁与读锁不互斥（多线程并发读）。
独享锁（Exclusive Lock）：也称为排它锁。每次只能由一个线程持有该锁，其他线程在尝试获取锁时会被阻塞。例如 Synchronized 、ReentrantLock 以及ReentrantReadWriteLock writeLock().lock()均是独享锁
共享锁（Shared Lock）：允许多个线程同时持有该锁，但当某个线程请求独占锁时，所有共享锁都必须释放。例如 ReentrantReadWriteLock readLock().lock()
3.1.1 AQS基础
AbstractQueuedSynchronizer（AQS）是 Java 并发包中用于实现锁、信号量、条件变量等同步器的基础框架。AQS 通过提供一个基础的同步原语（主要基于状态变量和等待队列）来简化复杂同步器的实现。它的设计采用了 模板方法模式，通过定义一些核心方法，允许子类根据需要实现具体的同步逻辑。AQS 的架构非常注重 状态控制 和 线程调度，通过 CAS 操作 和 FIFO 队列 来保证高效的线程管理。
AQS 的设计分为几个主要的模块，分别是：
1. 同步状态（state）
同步状态 state 是 AQS 的核心变量，用于标识同步器的当前状态。通常是一个 int 类型的字段。通过该状态，AQS 控制线程对资源的访问。
• 读写锁：state 表示当前锁的状态，如读锁数量和写锁是否被占用。
• 信号量：state 表示剩余许可的数量。
• 独占锁：state 为 0 表示锁空闲，非 0 表示锁已被占用。
通过 getState()、setState() 和 compareAndSetState() 方法对状态进行操作。state 的值通常是用来判定是否可以继续执行某个同步操作。
2. 等待队列（FIFO 队列）
AQS 内部维护一个 FIFO 双向链表，该队列用来管理所有等待资源的线程。每当线程无法获取到同步资源时，它会被加入到该队列中。
• 线程加入队列：当线程获取锁失败时，它会创建一个 Node 对象，加入到队列尾部。
• 线程等待：线程会在队列中等待唤醒。当锁释放后，队列头部的线程将被唤醒。
队列中的每个节点表示一个线程。通过该队列，AQS 可以管理多个线程的竞争，并实现线程的公平性、优先级等策略。每个 Node 结构包含以下信息：
• thread：等待线程。
• prev：前驱节点。
• next：后继节点。
• waitStatus：当前节点的状态，决定了节点是否需要被唤醒或者取消。3. 独占模式与共享模式
AQS 支持独占模式 和 共享模式两种主要的锁模式。
独占模式：一个线程获取资源后，其他线程无法获取资源，只有当前持有锁的线程可以操作该资源。ReentrantLock 就是典型的独占模式实现。独占模式处理方法如下：
• tryAcquire(int arg)：尝试独占锁，失败时进入等待队列。
• tryRelease(int arg)：释放独占锁，成功时唤醒队列中的下一个线程。
• acquire(int)：获取独占锁，失败时进入队列。
• release(int)：释放独占锁。共享模式：多个线程可以同时访问资源，只要资源足够。Semaphore 和 CountDownLatch 就是共享模式的实现。共享模式处理方法如下
• tryAcquireShared(int arg)：尝试获取共享锁。
• tryReleaseShared(int arg)：释放共享锁，唤醒共享模式下的线程。
• acquireShared(int)：获取共享锁。
• releaseShared(int)：释放共享锁。4. AQS 核心方法与模板方法
AQS 采用 模板方法设计模式，为子类提供了一些基本的同步框架，并留给子类实现具体的同步逻辑。子类通过重写以下几个方法来实现具体的同步器逻辑：
独占模式
• tryAcquire(int)：尝试获取独占锁。
• tryRelease(int)：尝试释放独占锁。
• isHeldExclusively()：检查是否是当前线程持有独占锁。共享模式
• tryAcquireShared(int)：尝试获取共享锁。
• tryReleaseShared(int)：尝试释放共享锁。等待队列管理
• addWaiter(Node.EXCLUSIVE)：向队列中添加独占线程。
• addWaiter(Node.SHARED)：向队列中添加共享线程。AQS 在这些方法中控制线程的同步、排队、唤醒等操作。
5. 节点（Node）
AQS 中的节点 (Node) 是等待队列中的基本单元。用于表示线程的状态管理线程的排队和唤醒，以及跟踪当前线程在等待队列中的位置。
节点状态：节点的 waitStatus 字段决定了节点的状态
• SIGNAL：当前节点需要被唤醒。
• CANCELLED：节点已经被取消。
• CONDITION：节点属于条件队列。
• PROPAGATE：共享模式中的传播信号。节点类型
• EXCLUSIVE：独占模式。
• SHARED：共享模式。6. 状态更新与线程管理
AQS 通过 CAS 操作、compareAndSetState 和 setState 等方法来更新 state，并通过等待队列管理线程的排队与唤醒。AQS 的基本操作如下：
1. 线程竞争
• 线程首先尝试获取资源，如果成功，则继续执行。
• 如果资源被其他线程占用，则进入等待队列，等待唤醒。
2. 唤醒与排队
• 当线程释放资源后，AQS 会从等待队列中唤醒下一个线程（根据等待队列的 FIFO 规则）。
3. 状态管理
• AQS 通过 state 控制资源的分配与释放。子类在具体实现时通过重写 tryAcquire 和 tryRelease 来实现对资源的控制。
3.2 锁的核心机制
3.2.1 基于AQS 实现读写锁
ReentrantReadWriteLock 通过内部定义一个 Sync 类来继承 AQS 并实现锁的具体逻辑。它继承自 AbstractQueuedSynchronizer，负责管理锁的状态。AQS 提供了基本的线程排队和唤醒机制，而 Sync 类通过重写 AQS 的方法来实现读锁和写锁的获取与释放。在 Sync 类中，读锁和写锁的实现都涉及到 tryAcquire、tryRelease、tryAcquireShared 和 tryReleaseShared 等方法。ReentrantReadWriteLock 通过继承 AQS 来实现其核心功能。Sync 类的核心方法实现：
1. tryAcquireShared()：用于尝试获取共享锁（读锁）。
2. tryAcquire()：用于尝试获取独占锁（写锁）。
3. tryReleaseShared()：释放共享锁。
4. tryRelease()：释放独占锁。
5. isWriteLocked()：判断当前状态是否为写锁。
6. isReadLocked()：判断当前状态是否为读锁。3.2.2. 读锁的获取与释放
获取读锁
高 16 位加 1 表示线程成功获取读锁，并记录线程的重入次数
static final int SHARED_SHIFT = 16;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
static int sharedCount(int c) { return c >>> SHARED_SHIFT; } //右移提取高16位
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; } //按位与提取低16位
protected final int tryAcquireShared(int unused) {
Thread current = Thread.currentThread(); // 获取当前线程
int c = getState(); // 获取同步状态 state
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return -1; // 判断当前是否存在写锁被占用
int r = sharedCount(c); // 获取当前的读锁计数（sharedCount(c) 从 state 的高 16 位解析读锁数）
if (!readerShouldBlock() && // 判断当前线程是否需要阻塞
r < MAX_COUNT && // 确保读锁计数没有超过最大值
compareAndSetState(c, c + SHARED_UNIT)) { // 使用 CAS 增加读锁计数（state 的高 16 位）
if (r == 0) { // 如果当前是第一个获取读锁的线程
firstReader = current; // 将当前线程设置为第一个读线程
firstReaderHoldCount = 1; // 初始化重入计数为 1
} else if (firstReader == current) {
firstReaderHoldCount++; // 增加该线程的重入计数
} else {
HoldCounter rh = cachedHoldCounter; // 获取当前线程的持锁计数缓存
if (rh == null || rh.tid != getThreadId(current)) // 如果缓存为空或线程 ID 不匹配，重新从 ThreadLocal 中获取
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0) // 如果计数为 0，将计数器重新设置到 ThreadLocal
readHolds.set(rh);
rh.count++; // 增加当前线程的读锁计数
}
return 1; // 成功获取读锁
}
return fullTryAcquireShared(current); // 如果 CAS 失败或条件不满足，进入更复杂的处理逻辑
}获取当前线程和同步状态 state，用于判断锁的当前状态
如果写锁计数（低 16 位）不为 0 且持有写锁的不是当前线程，返回 -1，表示读锁获取失败。
尝试获取读锁，判断是否满足获取读锁的条件：
当前线程是否需要阻塞（如写锁优先的策略）。
当前读锁计数未达到最大值。
使用 CAS 操作尝试增加读锁计数。
如果当前是第一个获取读锁的线程，将当前线程标记为 firstReader，初始化其重入计数为 1。
如果当前线程已经是 firstReader，仅增加其重入计数。
对于其他线程则获取或创建当前线程的持锁计数器 HoldCounter。更新线程的读锁计数，记录重入次数。
如果成功获取读锁，返回 1，表示成功。
如果 CAS 失败或其他条件未满足，调用 fullTryAcquireShared，进一步尝试获取锁（如公平模式下的队列操作等）。
读锁释放
释放时，高 16 位减 1；当高 16 位为 0 时，表示读锁完全释放。
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
if (firstReaderHoldCount == 1)
firstReader = null; // 如果当前线程是第一个读线程，并且只持有一次读锁，清空记录
else
firstReaderHoldCount--; // 否则减少该线程的持有次数
} else {
HoldCounter rh = cachedHoldCounter; // 从缓存中获取线程的锁计数器
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get(); // 如果缓存为空或线程 ID 不匹配，从 ThreadLocal 中获取
int count = rh.count;
if (count <= 1) {
readHolds.remove(); // 持有读锁次数为 1 或更少时，移除 ThreadLocal
if (count <= 0)
throw unmatchedUnlockException(); // 异常：尝试释放未持有的锁
}
--rh.count; // 减少当前线程的读锁计数
}
for (;;) {
int c = getState(); // 获取当前同步状态
int nextc = c - SHARED_UNIT; // 计算新状态，减少一个读锁
if (compareAndSetState(c, nextc)) // 如果状态变为 0，表示所有读锁都已释放
return nextc == 0;
}
}首先获取当前线程的引用，用于判断是哪个线程持有了读锁。
如果当前线程是第一个获取读锁的线程（firstReader），则使用一个简单的计数器 firstReaderHoldCount 来记录它的重入次数，避免使用更复杂的数据结构。
对于非第一个线程的情况，使用 ThreadLocal 存储每个线程的持有读锁次数：
从 cachedHoldCounter（缓存） 或 ThreadLocal 中获取当前线程的计数器。
减少当前线程的计数（rh.count），如果计数降为 0 或更少，移除 ThreadLocal。
使用 CAS（Compare-And-Swap） 操作更新同步状态 state。且每个读锁占用 SHARED_UNIT（常量，表示每次读锁的占用值）。如果更新后的 state 变为 0，说明所有读锁都已释放，此时可能会唤醒等待的写线程。
3.2.2 写锁的获取与释放
写锁获取
低 16 位加 1 表示线程成功获取写锁，并记录线程的重入次数
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread(); //获取当前线程的引用
int c = getState(); //获取当前锁的状态,包含写锁和读锁的计数
int w = exclusiveCount(c); //计算当前写锁计数
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread()) //如果没有写锁但存在读锁，或者当前线程不是写锁的拥有者，说明另一个线程持有写锁，则返回失败
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT) //如果写锁的数量超过预定义的最大计数 MAX_COUNT，抛出错误，防止锁计数溢出。
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires); //如果当前线程是锁的拥有者，则可以增加计数实现可重入。更新锁状态为 c + acquires
return true;
}
if (writerShouldBlock() || //检查是否需要阻止当前线程获取锁
!compareAndSetState(c, c + acquires)) //原子操作，尝试将状态从 c 更新为 c + acquires，确保线程安全
return false;
setExclusiveOwnerThread(current); //将当前线程设置为锁的独占拥有者
return true;
}获取当前线程对象，用于判断是否可以获取锁，以及处理锁的重入。
获取当前锁的状态值 c，这是一个整数，包含了锁的共享计数（读锁）和独占计数（写锁）。锁的状态由 读计数（高 16 位） 和 写计数（低 16 位）组成。
解析出写锁的计数（即低 16 位的值），表示当前锁被写锁持有的次数。
检查当前锁的状态是否非空，如果c != 0 说明当前锁已被持有，可能是读锁或写锁。
如果是当前线程持有写锁，则支持重入，直接增加计数并获取成功。
如果锁被其他线程持有，获取失败。
如果锁状态为 0，说明锁未被任何线程持有
判断当前线程是否应该被阻塞（公平/非公平策略）。
如果允许获取锁，通过 CAS 更新锁的状态并设置当前线程为独占持有线程。
写锁释放
低 16 位减 1；当低 16 位为 0 时，表示写锁完全释放
protected final boolean tryRelease(int releases) {
if (!isHeldExclusively()) //检查当前线程是否是锁的独占持有者。
throw new IllegalMonitorStateException();
int nextc = getState() - releases; //计算释放后锁的状态值。
boolean free = exclusiveCount(nextc) == 0; //从状态值 nextc 中提取独占锁计数
if (free) //如果锁计数变为 0，表示锁已经完全释放。
setExclusiveOwnerThread(null); //将锁的拥有者线程设置为 null，表示锁不再属于任何线程
setState(nextc); //更新锁的状态值为 nextc，完成对锁计数的更新
return free;
}检查当前线程是否是锁的独占持有者。如果当前线程没有持有写锁，却试图释放写锁，抛异常
获取当前锁的状态值，然后减去释放的次数 计算出释放后的新状态
如果低16位结果为 0，说明写锁已经完全释放，表示锁处于空闲状态。
如果锁已经完全释放，将独占持有线程置为 null，表明锁已经释放。
更新锁的状态值，如果还有未释放的重入次数，状态值会被更新但不会清空独占线程。
3.3 公平锁与非公平锁
ReentrantReadWriteLock 支持公平锁和非公平锁两种锁模式。
公平锁的设计原则是“先来先服务”，即按照线程请求锁的时间顺序来分配锁。公平锁在避免线程饥饿问题上表现更好，但由于要维护队列和顺序，它可能导致性能开销稍高。公平锁通常通过队列（如 FIFO 队列）来维护线程的请求顺序。在 Java 的 ReentrantLock 中，通过设置 ReentrantLock(true) 可以创建一个公平锁。当线程尝试获取锁时，公平锁会检查等待队列：如果队列为空，线程可以直接获取锁；如果队列不为空，线程会被加入队列，并等待前面的线程先完成。当锁被释放时，会按照队列的顺序唤醒下一个线程。
优点：避免线程饥饿，保证所有线程都能公平地获取锁。顺序明确，适用于需要严格控制执行顺序的场景。
缺点：由于需要维护队列，会增加系统开销。在高并发情况下性能可能较低，因为频繁切换线程会影响效率。
非公平锁的设计原则是“竞争优先”，即线程可以直接尝试获取锁，而不考虑其他线程的请求顺序。它的效率通常比公平锁高，但可能导致某些线程长期无法获取锁（线程饥饿）。默认情况下，ReentrantLock 是非公平锁。通过设置 ReentrantLock(false) 或直接使用默认构造函数即可创建非公平锁。当线程尝试获取锁时，非公平锁会直接抢占：如果锁是空闲的，线程直接获取锁；如果锁被占用，线程可能被放入等待队列，但优先考虑重新竞争的线程，并且等待队列中的线程不一定严格按照请求顺序唤醒。
优点：性能较高，因为减少了维护队列的开销。更适合高并发场景，锁的获取速度更快。更适合高并发场景，锁的获取速度更快。
缺点：可能导致线程饥饿问题，因为某些线程可能长期得不到锁的竞争机会。顺序性差，不适合对顺序要求严格的场景。
3.4 锁降级
锁降级是 ReentrantReadWriteLock 提供的一项灵活功能，是指在持有写锁的情况下，通过先获取读锁，再释放写锁，使锁从写锁降级为读锁的过程。它是一种提高并发性能的机制，避免了在某些场景下完全释放写锁后读锁竞争导致的线程切换和性能损耗。
锁降级的流程只能从写锁降级到读锁，并且顺序严格：
获取写锁：线程首先获取写锁，用于更新数据。
获取读锁：在持有写锁的同时获取读锁，确保在锁释放期间不会被其他线程干扰。
释放写锁：释放写锁后，读锁仍然保持，允许其他线程并发读取。
注意：ReentrantReadWriteLock 只支持锁降级，不支持锁升级（从读锁直接升级为写锁），线程必须释放读锁后再尝试获取写锁。
应用示例：
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class LockDowngradeExample {
private final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
private int sharedData = 0;
public void lockDowngrade() {
ReentrantReadWriteLock.WriteLock writeLock = lock.writeLock();
ReentrantReadWriteLock.ReadLock readLock = lock.readLock();
writeLock.lock();
try {
sharedData++;
System.out.println(Thread.currentThread().getName() + " 写入数据：" + sharedData);
readLock.lock();
System.out.println(Thread.currentThread().getName() + " 获取读锁进行降级");
} finally {
writeLock.unlock();
System.out.println(Thread.currentThread().getName() + " 释放写锁");
}
try {
System.out.println(Thread.currentThread().getName() + " 读取数据：" + sharedData);
} finally {
readLock.unlock();
System.out.println(Thread.currentThread().getName() + " 释放读锁");
}
}
public static void main(String[] args) {
LockDowngradeExample example = new LockDowngradeExample();
Thread t1 = new Thread(example::lockDowngrade, "线程1");
Thread t2 = new Thread(example::lockDowngrade, "线程2");
t1.start();
t2.start();
}
}3.5 锁的重入
重入锁（Reentrant Lock）是一种允许线程在持有锁的情况下，重复获取该锁的机制（也叫递归锁）。线程在获得锁后，可以多次进入锁保护的代码区域，而不会被阻塞。锁内部会维护一个计数器，用于记录锁被同一线程获取的次数，以及一个标记记录当前持有锁的线程。每次锁被释放时，计数器会减 1，直到计数器为 0，锁才真正释放。
非可重入锁（Non-Reentrant Lock）的线程在获取锁后不能重复进入锁保护的代码区域。如果线程在持有锁时再次请求锁，会导致死锁（因为锁已经被占用，而该线程也无法释放锁）。其中，synchronized 隐式实现了重入锁，ReentrantLock和ReentrantReadWriteLock读写锁中显示支持了重入机制。
synchroized重入举例
public class RecursiveReentrantExample {
public synchronized void recursiveMet(int count) {
if (count > 0) {
System.out.println(Thread.currentThread().getName() + " 进入 recursiveMet，count = " + count);
recursiveMet(count - 1); // 递归调用
System.out.println(Thread.currentThread().getName() + " 离开 recursiveMet，count = " + count);
}
}
public static void main(String[] args) {
RecursiveReentrantExample example = new RecursiveReentrantExample();
Thread thread = new Thread(() -> example.recursiveMet(3), "线程1");
thread.start();
}
}
总结：
• 读锁重入：同一个线程可以多次获取读锁，不会被阻塞。
• 写锁重入：同一个线程持有写锁后，可以再次获取写锁。
写锁与读锁的关系：
• 持有写锁的线程可以获取读锁（支持锁降级）。
• 持有读锁的线程不能直接获取写锁（不支持锁升级）。
四. yarn的ReentrantReadWriteLock应用举例
4.1 作业提交（读锁）
//提交作业
protected void submitApplication(
ApplicationSubmissionContext submissionContext, long submitTime,
String user, String clientHost) throws YarnException {
ApplicationId applicationId = submissionContext.getApplicationId();
RMAppImpl application = createAndPopulateNewRMApp(
submissionContext, submitTime, user, false, -1, null, clientHost);
......
}
//创建新的应用程序
private RMAppImpl createAndPopulateNewRMApp(
ApplicationSubmissionContext submissionContext, long submitTime,
String user, boolean isRecovery, long startTime,
RMAppState recoveredFinalState, String clientHost) throws YarnException {
ApplicationPlacementContext placementContext = null;
......
if (!isRecovery) {
Priority appPriority = scheduler.checkAndGetApplicationPriority(
submissionContext.getPriority(), userUgi,
submissionContext.getQueue(),
applicationId);
submissionContext.setPriority(appPriority);
}
......
return application;
}
//检查作业优先级
public Priority checkAndGetApplicationPriority(
Priority priorityRequestedByApp, UserGroupInformation user,
String queueName, ApplicationId applicationId) throws YarnException {
try {
readLock.lock();
Priority appPriority = priorityRequestedByApp;
if (null == appPriority) {
appPriority = this.appPriorityACLManager.getDefaultPriority(queueName,
user);
if (null == appPriority) {
appPriority = this.queueManager.getDefaultPriorityForQueue(queueName);
}
......
return appPriority;
} finally {
readLock.unlock();
}
}提交新的作业时，RM调用 createAndPopulateNewRMApp 方法创建一个新的应用程序对象 RMAppImpl，并为其填充所需的初始数据createAndPopulateNewRMApp（），然后验证作业的优先级是否正确scheduler.checkAndGetApplicationPriority()。在验证和调整优先级时可能会访问共享资源，例如：
• appPriorityACLManager：用于检查应用程序优先级相关的权限。
• queueManager：用于获取队列的默认优先级。
• getMaxClusterLevelAppPriority()：用于获取集群级别的最大优先级。
这些资源是多线程共享的，多个线程可能同时对这些资源进行访问。如果多个线程同时对这些资源进行修改，可能会导致数据的不一致。使用readLock.lock()既可以保障数据的一致性同时提高多个作业提交的并发性能。
4.2 容器的释放（写锁）
private void internalReleaseResource(Resource clusterResource,
FiCaSchedulerNode node, Resource releasedResource) {
try {
writeLock.lock();
super.releaseResource(clusterResource, releasedResource,
node.getPartition());
if (LOG.isDebugEnabled()) {
LOG.debug(
"completedContainer " + this + ", cluster=" + clusterResource);
}
} finally {
writeLock.unlock();
}
}
protected void releaseResource(Resource clusterResource,
Resource resource, String nodePartition) {
try {
writeLock.lock();
queueUsage.decUsed(nodePartition, resource);
CSQueueUtils.updateQueueStatistics(resourceCalculator, clusterResource,
this, labelManager, nodePartition);
--numContainers;
} finally {
writeLock.unlock();
}
}internalReleaseResource() 会首先获取写锁
然后调用父类的 releaseResource() 方法
releaseResource()获取写锁
releaseResource() 减少 nodePartition 中使用的资源量，更新与队列相关的统计信息然后减少容器数
releaseResource()释放资源后释放写锁
internalReleaseResource()释放写锁
更多技术和产品文章，请关注👆
如果您对哪个产品感兴趣，欢迎留言给我们，我们会定向邀文~
360智汇云是以"汇聚数据价值，助力智能未来"为目标的企业应用开放服务平台，融合360丰富的产品、技术力量，为客户提供平台服务。
目前，智汇云提供数据库、中间件、存储、大数据、人工智能、计算、网络、视联物联与通信等多种产品服务以及一站式解决方案，助力客户降本增效，累计服务业务1000+。
智汇云致力于为各行各业的业务及应用提供强有力的产品、技术服务，帮助企业和业务实现更大的商业价值。
官网：https://zyun.360.cn 或搜索“360智汇云”
客服电话：4000052360
欢迎使用我们的产品！😊
扫一扫
486
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
