1 基本概念
1.1 定义
重入锁是一类允许同一线程在已持有锁的前提下，继续再次获取同一把锁的同步工具。它的设计重点不在于放宽互斥，而是在保持排他访问的同时，避免线程因为“自己把自己挡住”而无法继续执行。
1.2 与普通锁的区别
普通锁通常只记录“是否已被占用”，并不区分持有者是谁；一旦同一线程重复申请，就可能进入阻塞状态。重入锁则会识别当前持有锁的线程，如果请求者与持有者相同，就允许再次进入，而不是立即等待。
1.3 重入次数与持有者线程
重入锁一般会保存两个核心信息：当前持有者线程，以及该线程累计获取锁的次数。每次同一线程再次加锁，次数都会递增；每次解锁则递减。只有当计数归零时，锁才算真正释放。
1.4 适用场景
这类锁常用于递归函数、层层调用的业务接口、对象内部多个方法互相调用的场合。它也常出现在需要把若干公共操作拆分为多个小函数的设计中，以便在不破坏线程安全的前提下提高代码复用度。
2 工作原理
2.1 锁状态记录
重入锁的实现通常依赖一份状态记录，用来判断锁是否空闲、由谁占有，以及当前处于第几次重入。相比简单的互斥标记，这种状态更细致，也更适合复杂调用过程。
2.1.1 持有线程标识
锁内部会保存一个线程标识，用于区分“本线程再次请求”与“其他线程竞争”。这个标识是实现重入判断的关键，也是后续计数管理的基础。
2.1.2 计数器机制
除线程标识外，锁还会维护一个重入计数器。初次获取时计数通常设为1，随后每次同线程重复进入都继续累加；当释放时逐步减少，直到恢复为空闲状态。
2.2 加锁流程
2.2.1 首次获取
当锁为空闲时，请求线程会获得锁的控制权，并成为新的持有者。此时系统会登记该线程身份，同时把重入次数设为初始值。
2.2.2 重复获取
如果持有锁的线程再次请求同一把锁，系统不会将其视为新的竞争者，而是直接允许进入，并把计数加一。这样就避免了在同一调用链内部出现自我阻塞。
2.3 释放流程
2.3.1 计数递减
线程执行完受保护的代码后，需要按获取顺序对应地释放锁。每次解锁通常只让重入计数减一，因此一次“再进入”并不会导致锁立即腾空。
2.3.2 完全释放
当计数减到零时，说明该线程已经退出所有嵌套层级，锁才会真正转交给等待中的其他线程。此时持有者标识也会被清除，锁回到可竞争状态。
3 类型与实现
3.1 递归互斥锁
递归互斥锁是重入锁的常见形态之一，强调同一线程可以多次锁定同一个资源。它通常以“互斥”为基础，再叠加线程识别和递归计数逻辑，因此也可视为带重入能力的互斥锁。
3.2 显式重入锁
显式重入锁一般把“加锁”“解锁”与“当前持有者管理”明确暴露给使用者或运行时框架。它往往配套更丰富的控制能力，例如可中断等待、定时等待以及条件配合等，适合更复杂的同步需求。
3.3 语言与平台实现
不同编程语言和运行时对重入锁的命名、接口和细节实现并不相同，但核心思想大体一致：识别持有线程、维护重入次数、在适当时机唤醒竞争者。
3.3.1 Java中的ReentrantLock
Java中的 ReentrantLock 是典型的显式重入锁实现。它支持重入、可中断获取、超时等待以及公平策略，并可与条件对象配合使用，适合需要更灵活控制的并发场景。
3.3.2 Python中的RLock
Python中的 RLock 主要用于解决同一线程在嵌套调用中重复申请锁的问题。它常见于对象内部方法之间的相互调用场景，尤其适用于需要保护共享状态但又不想调整函数结构的代码。
3.3.3 其他语言中的对应机制
许多语言和平台也提供了类似能力，只是名称不同，例如递归锁、可重入互斥量或重入型同步原语。它们在接口层面可能简化或扩展某些功能，但基本行为通常一致。
4 核心特性
4.1 可重入性
可重入性是这类锁最核心的属性。它使得同一线程在持有锁时还能再次进入受保护区域，从而减少因为函数分层、递归或回调结构带来的同步冲突。
4.2 可中断获取
部分重入锁允许线程在等待锁时响应中断信号。这样一来，线程不必无条件挂起，系统也能更灵活地处理取消操作、超时控制或任务退出。
4.3 超时获取
超时获取表示线程在等待锁时可以设定最大等待时长。若在规定时间内未获得锁，则返回失败或进入其他处理逻辑，避免无限期阻塞。
4.4 公平锁与非公平锁
公平锁通常倾向于按照请求顺序分配资源，减少“插队”现象；非公平锁则更注重吞吐效率，可能允许新来的线程在某些条件下先获得锁。两者各有取舍，具体选择取决于性能与公平性的平衡。
4.5 条件变量支持
重入锁常与条件变量协同使用，以便在线程等待某一状态变化时释放锁并挂起，随后在条件满足时再恢复执行。这种组合在生产者消费者模型和状态同步中很常见。
5 使用方法
5.1 基本加锁与解锁
使用重入锁时，通常遵循“获取—执行—释放”的基本模式，并且释放次数应与获取次数对应。若在嵌套路径中多次进入，同样需要逐层退出，确保计数恢复到零。
5.2 递归函数中的使用
递归算法常会反复进入同一处理函数，如果该函数内部需要访问共享资源，重入锁能避免每一层递归都卡在同一把锁上。这样既保留了递归结构，也维持了线程安全。
5.3 嵌套调用中的使用
当一个受锁保护的方法调用另一个同样需要同步的方法时，重入锁尤其有用。外层已经持锁的情况下，内层无需额外绕路，就能继续访问同一资源，从而让接口拆分更自然。
5.4 结合条件等待
在需要等待某个条件成立时，重入锁经常和条件变量一起使用。线程可以先释放锁进入等待，条件满足后再重新获得锁继续执行，这种方式有助于协调多个线程间的步骤顺序。
6 优缺点分析
6.1 优点
6.1.1 避免自锁死
重入锁能够识别“自己等待自己”的情况，因此不会让同一线程因重复进入而陷入停滞。这对于复杂调用链和分层设计尤其重要。
6.1.2 提升代码复用性
借助重入锁，多个方法可以共享同一套同步保护逻辑，而不必为了避免重复加锁去重写代码结构。这样更利于拆分功能与维护接口。
6.1.3 适合复杂调用链
在对象内部调用、回调嵌套、递归展开等场景中，重入锁往往能提供更顺畅的同步体验，减少额外协调成本。
6.2 缺点
6.2.1 开销更高
相比简单锁，重入锁通常需要维护线程身份和计数信息，因此实现上会带来额外成本。在高频竞争环境中，这种开销可能更明显。
6.2.2 滥用风险
因为它“更好用”，开发者有时会不加区分地使用重入锁，结果让同步范围扩大，进而降低并发度，甚至掩盖更合理的设计方案。
6.2.3 忽视锁设计问题
重入性只能解决“重复进入”的技术障碍，并不能代替良好的并发设计。若临界区划分不合理，仍可能出现性能下降、等待堆积或复杂依赖问题。
7 常见问题
7.1 忘记解锁
若获取次数与释放次数不匹配，锁会长期保持占用状态，导致其他线程无法进入。对于重入锁而言，这类错误更隐蔽，因为表面上可能已经执行了部分解锁，但计数尚未归零。
7.2 锁粒度过大
将过多逻辑放进同一把锁保护范围内，会减少线程并行度。即便使用重入锁，也不应把它当作“万能保险”，否则容易让系统退化为串行执行。
7.3 死锁与活锁
重入锁可以避免自锁死，但并不能消除所有死锁风险。若多个线程以不同顺序争夺多把锁，仍可能形成循环等待；而在某些策略不当的情况下，也可能出现不断重试却始终无法推进的活锁。
7.4 递归深度过深
在递归层级很深的情况下，重入次数会不断增加，虽然锁本身能正常工作，但整个调用栈的资源消耗可能变大。此时需要同时关注算法结构和栈空间限制。
7.5 线程安全与重入性的误解
“可重入”不等于“自动线程安全”。它只说明同一线程可以重复进入同一把锁，并不意味着对象内部所有状态都已经正确保护，也不代表多线程访问一定没有问题。
8 应用场景
8.1 数据结构保护
在保护共享集合、缓存或树结构时，重入锁可用于统一管理读写入口，尤其当数据操作会通过多个辅助函数完成时，能减少重复上锁带来的麻烦。
8.2 对象方法级同步
对象的公开方法和私有辅助方法常会相互调用。使用重入锁后，外层方法持锁进入，内层方法仍可安全执行，从而实现较自然的方法级同步。
8.3 递归算法实现
在递归遍历、回溯搜索或分治处理中，如果需要访问共享状态，重入锁能让每一层递归都遵循同一套保护规则，不必为每次递归单独设计同步逻辑。
8.4 框架内部并发控制
许多框架或库会在内部维护状态机、任务队列或资源池。重入锁适合用来协调这些内部组件，因为它既能保证互斥，又不会因为内部层层调用而产生自我阻塞。
9 对比与扩展
9.1 与互斥锁对比
互斥锁强调“同一时刻只能有一个线程持有”，而重入锁在此基础上增加了“同一线程可重复进入”的能力。前者结构更简单，后者更适合复杂调用关系。
9.2 与读写锁对比
读写锁侧重区分读操作与写操作，允许多个读者并发，但写入通常独占；重入锁则不区分读写角色，主要解决同线程重复获取问题。两者关注点不同，适用范围也不同。
9.3 与自旋锁对比
自旋锁在等待时会主动循环占用处理器时间，适合极短临界区；重入锁通常会进入阻塞等待，更适合可能涉及较长处理流程的场景。若临界区较复杂，重入锁往往更稳妥。
9.4 与信号量对比
信号量更像是一种资源计数器，可允许多个线程按许可数进入；重入锁则主要用于单线程排他访问，并支持持有者再次进入。两者解决的问题并不相同。
10 相关概念
10.1 临界区
临界区是指访问共享资源时必须避免并发冲突的代码段。重入锁往往就是围绕临界区设计，用于控制进入与退出。
10.2 死锁
死锁是多个执行实体相互等待对方释放资源而无法继续推进的状态。重入锁能减少某些由重复加锁引起的阻塞，但并不能彻底消除死锁。
10.3 线程安全
线程安全表示多个线程同时访问同一资源时，不会破坏数据一致性或程序正确性。重入锁是实现线程安全的常用工具之一，但并非唯一手段。
10.4 条件变量
条件变量用于线程间的等待与通知协作，常与锁配套使用。在线程等待条件变化时，锁负责保护共享状态，条件变量负责协调唤醒时机。