【并发编程】AbstractQueuedSynchronizer（AQS）JDK1.8 源码分析

最新推荐文章于 2026-06-21 19:47:07 发布
原创 最新推荐文章于 2026-06-21 19:47:07 发布 · 673 阅读 · 18 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测
标签
#java

AbstractQueuedSynchronizer（AQS）JDK1.8 源码分析

一、核心概念

1.1 核心实现机制

1.1.1 可重入性

AQS的重入性（Reentrant）是指同一个线程能够多次获取同一个锁而不会死锁。

  1. 什么是重入性问题：
    public class Example {
    private final ReentrantLock lock = new ReentrantLock();
    
    public void outer() {
        lock.lock();  // 第一次获取锁
        try {
            inner();  // 调用inner方法
        } finally {
            lock.unlock();
        }
    }
    
    public void inner() {
        lock.lock();  // 同一线程第二次获取锁
        try {
            // do something
        } finally {
            lock.unlock();
        }
    }
}
  2. 为什么需要重入性：
    • 避免死锁：如果不支持重入，上述代码会死锁
    • 方法嵌套调用：同一个线程内的方法调用链需要多次获取相同的锁
    • 继承场景：子类方法调用父类的同步方法时也需要重入
  3. AQS如何实现重入：
    // ReentrantLock.Sync类中非公平锁的实现
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) { // 锁未被持有
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) { // 检查是否是当前线程持有锁
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc); // 增加重入计数
        return true;
    }
    return false;
}
  4. 使用注意事项：
    • 注意unlock的次数要与lock的次数匹配
    • 合理使用try-finally确保锁的释放
    • 避免过深的重入，可能影响性能
    • 考虑使用Lock接口的其他方法（如tryLock）来增加灵活性

1.1.2 公平性&非公平性

AQS的公平锁和非公平锁，在实现方式上的区别是，在锁空闲时，是否调用了hasQueuedPredecessors()方法，该方法用于检查队列是否有前驱节点。

protected final boolean tryAcquire(int acquires) {
     final Thread current = Thread.currentThread();
     int c = getState();
     if (c == 0) {
          // 关键区别：公平锁会先调用hasQueuedPredecessors()方法检查队列是否有前驱节点
          if (!hasQueuedPredecessors() &&
               compareAndSetState(0, acquires)) {
               setExclusiveOwnerThread(current);
               return true;
          }
      }
      else if (current == getExclusiveOwnerThread()) {
           int nextc = c + acquires;
           if (nextc < 0)
               throw new Error("Maximum lock count exceeded");
           setState(nextc);
           return true;
      }
      return false;
}

1.1.3 中断处理

1.2 核心属性

public abstract class AbstractQueuedSynchronizer {
    /** 同步状态 */
    private volatile int state;

    /** 等待队列的头节点 */
    private transient volatile Node head;

    /** 等待队列的尾节点 */
    private transient volatile Node tail;
}

1.3 Node详解

static final class Node {
    /** 表示共享模式 */
    static final Node SHARED = new Node();
    
    /** 表示独占模式 */
    static final Node EXCLUSIVE = null;

    /** 
     * waitStatus 值，表示线程已取消（值为1）
     * 由于超时或中断，节点会被设置为取消状态，被取消的节点时不会再变化状态
     */
    static final int CANCELLED =  1;
    
    /** 
     * waitStatus 值，表示后继线程需要被唤醒（值为-1）
     * 后继节点入队时，会将前驱节点设置为 SIGNAL
     */
    static final int SIGNAL    = -1;
    
    /** 
     * waitStatus 值，表示节点在条件队列中（值为-2）
     * 当前节点在 condition 队列中等待
     */
    static final int CONDITION = -2;
    
    /**
     * waitStatus 值，用于共享模式，表示状态需要向后传播（值为-3）
     * 在共享模式下，PROPAGATE 状态的节点会向后传播唤醒的操作
     */
    static final int PROPAGATE = -3;

    /** 
     * 等待状态，初始值为 0
     * 可能值包括：CANCELLED(1)、SIGNAL(-1)、CONDITION(-2)、PROPAGATE(-3)、0(初始状态)
     */
    volatile int waitStatus;

    /** 前驱节点的引用 */
    volatile Node prev;

    /** 后继节点的引用 */
    volatile Node next;

    /** 当前节点封装的线程 */
    volatile Thread thread;

    /** 下一个等待节点，用于条件队列 */
    Node nextWaiter;
}

二、加锁实现详解

在这里插入图片描述

2.1 acquire() 方法 - 获取锁的入口

public final void acquire(int arg) {
    // 1. 尝试获取锁，如果成功则直接返回
    // 2. 获取失败，将当前线程包装成 Node 并加入队列
    // 3. acquireQueued 返回 true 表示在等待过程中被中断
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt(); // 重新设置中断状态
}

2.2 tryAcquire() - 尝试获取锁

这里以 ReentrantLock 的公平锁为例：

protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {  // 锁未被占用
        // 检查前面是否已经有在排队的，为实现公平性
        if (!hasQueuedPredecessors() &&
        	// CAS不成功则说明同时有其他线程竞争到了锁
            compareAndSetState(0, acquires)) {
            // 能进来说明已经获取到锁，这里标记一下(独占线程)
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {  // 处理重入的情况
        int nextc = c + acquires;
        if (nextc < 0)  // 检查溢出
            throw new Error("Maximum lock count exceeded");
        setState(nextc);  // 设置重入次数
        return true;
    }
    return false;
}

2.3 addWaiter() - 加入等待队列

private Node addWaiter(Node mode) {
    // 创建新节点，将当前线程塞进去
    Node node = new Node(Thread.currentThread(), mode);
    
    // 判断队列是否已经初始化，如果已经初始化，则尝试快速入队（尾部入队）
    Node pred = tail;
    if (pred != null) {
    	// 如果队列已初始化，则首先将当前队尾，设置为当前node的前驱
        node.prev = pred;
        // 然后，使用 CAS 把当前node设置成队尾
        if (compareAndSetTail(pred, node)) {
        	// CAS成功，说明当前node已经成为队尾。
        	// 紧接着将自己与之前的队尾相连，结合前面的{node.prev = pred} 这样就实现了和之前的尾结点双向连接了。
            pred.next = node;
            return node;
        }
        // 如果上面的CAS失败，说明有线程在竞争入队
    }
    
    // 如果队列未初始化 或者 快速入队失败(CAS失败,有其他线程竞争入队)，则进入完整入队方法(自旋方式入队)
    enq(node);
    return node;
}

// 自旋方式入队
private Node enq(final Node node) {
    for (;;) {
        Node t = tail;
        // 判断是否需要初始化队列
        if (t == null) {
        	// 进行初始化
        	// 这里为什么要CAS呢，因为可能同时有多个线程进来
            if (compareAndSetHead(new Node()))
            	// 注意：这里并没有return!!! 所以紧接着下一次循环就会进到下面的else
                tail = head;
        } else {
        	// 这里的逻辑和addWaiter()中的快速入队一样，都是为了把当前节点设置成队尾，设置成功后结束自旋。
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

2.4 acquireQueued() - 自旋获取锁

final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;  // 标记是否成功获取锁
    try {
        boolean interrupted = false;  // 标记是否被中断过
        for (;;) {
            final Node p = node.predecessor();  // 获取前驱节点
            
            // 如果前驱是头节点，说明轮到自己了，尝试获取锁
            if (p == head && tryAcquire(arg)) {
                setHead(node);  // 获取成功，将自己设置为头节点
                p.next = null;  // 帮助 GC
                failed = false;
                return interrupted;
            }
            
            // 判断获取锁失败后，是否需要阻塞(挂起当前线程)
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
        	// tryAcquire()抛异常的情况下，会进到这里
            cancelAcquire(node);
    }
}

2.5 shouldParkAfterFailedAcquire() - 检查是否需要阻塞

private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus;
    if (ws == Node.SIGNAL)  // 前驱节点已经准备好唤醒后继节点
        return true;
    if (ws > 0) {  // 前驱节点已取消，跳过取消的节点
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0);
        pred.next = node;
    } else {  // 将前驱节点设置为SIGNAL状态
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

三、解锁实现详解

3.1 release() - 释放锁

public final boolean release(int arg) {
    if (tryRelease(arg)) {
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);  // 唤醒后继节点
        return true;
    }
    return false;
}

3.2 unparkSuccessor() - 唤醒后继节点

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);

    Node s = node.next;
    // 如果后继节点为空或已取消，从尾部开始找到最前面的一个未取消的节点
    if (s == null || s.waitStatus > 0) {
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);  // 唤醒线程
}

四、Node 状态转换

4.1 状态值定义

  • CANCELLED (1)：线程已取消
  • SIGNAL (-1)：后继节点需要唤醒
  • CONDITION (-2)：节点在条件队列中
  • PROPAGATE (-3)：状态需要向后传播
  • 0：初始状态

4.2 状态转换流程图

        初始状态(0)
   ↙        ↓        ↘
SIGNAL   CANCELLED  CONDITION
   ↓         ↓         ↓
PROPAGATE  (终态)    SIGNAL

4.3 主要状态转换场景

  1. 初始状态 → SIGNAL：
    场景：后继节点入队时
    目的：标识后继节点需要被唤醒

  2. 初始状态 → CANCELLED：
    场景：线程等待超时或被中断
    目的：标识节点已失效

  3. CONDITION → SIGNAL：
    场景：条件满足，节点从条件队列转移到同步队列
    目的：重新参与锁的竞争

六、性能优化

6.1 CAS操作

  • 使用 CAS 避免锁竞争
  • 快速设置 tail 节点
  • 原子更新状态
// Code Example：
public class CASExample extends AbstractQueuedSynchronizer {
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long stateOffset;
    private static final long headOffset;
    private static final long tailOffset;

    static {
        try {
            stateOffset = unsafe.objectFieldOffset(
                AbstractQueuedSynchronizer.class.getDeclaredField("state"));
            headOffset = unsafe.objectFieldOffset(
                AbstractQueuedSynchronizer.class.getDeclaredField("head"));
            tailOffset = unsafe.objectFieldOffset(
                AbstractQueuedSynchronizer.class.getDeclaredField("tail"));
        } catch (Exception ex) { throw new Error(ex); }
    }

    // CAS更新状态
    protected final boolean compareAndSetState(int expect, int update) {
        return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
    }
}

6.2 自旋优化

  • 尝试获取锁时先自旋
  • 减少不必要的线程阻塞
  • 适应性自旋
// Code Example：
public class SpinningExample extends AbstractQueuedSynchronizer {
    private static final int MAX_SPIN_COUNT = 100;

    public void lock() {
        // 先尝试自旋获取
        int spinCount = 0;
        while (spinCount < MAX_SPIN_COUNT) {
            if (compareAndSetState(0, 1)) {
                setExclusiveOwnerThread(Thread.currentThread());
                return;
            }
            spinCount++;
            // 适应性自旋：如果上次自旋成功，则多自旋几次
            if (spinCount < previousSuccessfulSpins * 2) {
                Thread.onSpinWait(); // Java 9+ specific
            }
        }
        // 自旋失败，进入正常的锁获取流程
        acquire(1);
    }
}

6.3 队列优化

  • 快速入队尝试
  • 双向链表结构
  • 跳过取消节点
// Code Example：
public class QueueOptimization extends AbstractQueuedSynchronizer {
    private Node enq(final Node node) {
        for (;;) {
            Node t = tail;
            if (t == null) {
                // 初始化队列
                if (compareAndSetHead(new Node())) {
                    tail = head;
                }
            } else {
                // 快速入队尝试
                node.prev = t;
                if (compareAndSetTail(t, node)) {
                    t.next = node;
                    return t;
                }
                // 处理取消的节点
                Node pred = node.prev;
                while (pred.waitStatus > 0) {
                    node.prev = pred = pred.prev;
                }
                pred.next = node;
            }
        }
    }
}
【JUC-AQS】JDK17 AQS源码分析
星光不问赶路人的博客
06-06 1261
在学习阳哥的的时候，阳哥讲AQS用的是JDK8，我用的是JDK17，想着自己分析一下，分析完之后发现JDK17与JDK8还是有些不同的，感觉更高效了。
深入解析 Java 8 中的 AbstractQueuedSynchronizer（AQS）：原理、应用与源码分析
持续输出Java相关知识
06-30 1002
在 Java 多线程编程中，同步是确保线程安全的关键。Java 并发包（java.util.concurrent）提供了许多高级工具，如 ReentrantLock、Semaphore 和 CountDownLatch，这些工具的底层都依赖于一个强大的框架——AbstractQueuedSynchronizer（AQS）。AQS 由并发大师 Doug Lea 设计，是 Java 并发包的核心组件之一。它通过一个原子整数状态（state）和 FIFO 等待队列管理线程竞争，提供了独占和共享两种同步模式。
【AQS】JDK1.8 源码分析 之 AbstractQueuedSynchronizer
植富宝
01-12 292
好几年没有更新博客了，满屋子的蜘蛛网
JUC AQS ReentrantLock源码分析（一）
热门推荐
java_lyvee的专栏
08-09 3万+
Java的内置锁一直都是备受争议的，在JDK 1.6之前，synchronized这个重量级锁其性能一直都是较为低下，虽然在1.6后，进行大量的锁优化策略,但是与Lock相比synchronized还是存在一些缺陷的：虽然synchronized提供了便捷性的隐式获取锁释放锁机制（基于JVM机制），但是它却缺少了获取锁与释放锁的可操作性，可中断、超时获取锁，且它为独占式在高并发场景下性能大打折扣。...
基于java Web 训练管理系统设计与实现 源码 论文
qq_251836457的博客
06-17 1912
用户信息实体，主要包括 用户编号,用户名,密码,姓名,性别,出生日期,证件号,民族,政治面貌,单位,入伍时间,照片,班级,排 等信息实体。1 用户( 用户编号,用户名,密码,姓名,性别,出生日期,证件号,民族,政治面貌,单位,入伍时间,照片,班级,排 )讨论信息实体，主要包括 讨论编号,疑问,说明,发布人,发布时间,状态,回答 等信息实体。系统主要用户实体,班级实体,排实体,科目实体,成绩实体,教学视频实体,教学理论实体,讨论实体，如图所示。班级信息实体，主要包括 班级编号,班级 等信息实体。
架构--数据库层面--读写分离
在技术领域里形成深刻，全面的认识，知道来龙去脉，深入浅出的讲到实用点。
06-21 374
快速入门/学习：推荐方案一 (+ AOP)，能让你深入理解原理，实现也直接。生产环境/复杂需求：推荐方案二 (ShardingSphere-JDBC)，它功能强大且对代码侵入小，能更好地应对未来扩展。大规模/运维主导：可考虑方案三 (独立中间件)，实现应用与数据库的解耦。另外要强调一下，springboot直接连mycat就可以了，在mycat的配置文件里做配置，实现主从分离。
24-Django请求全链路-WSGI到数据库响应的完整旅程
weixin_44081096的博客
06-15 1471
你点了浏览器的"刷新"按钮，0.5 秒后页面渲染完毕。这 0.5 秒里发生了什么？本文把 Django 处理一个 HTTP 请求的完整链路拆为六个步骤：WSGI Server 接收 TCP 连接 → 中间件栈的洋葱模型逐层处理 → URL 路由匹配 → View 执行业务逻辑 → ORM 生成 SQL 并发送到数据库 → Template 渲染或 JSON 序列化返回响应。每一步都配有对应的源码位置和关键代码片段，读完你能对一个请求的全生命周期建立起清晰的空间模型。穿插真实调试经历——一个中间件错误导致所有
自己动手写一个spring之IOC_3
wang0907的博客
06-15 777
本文来继续增加IOC部分的功能，增加基于@Autowired注解注入bean的功能。。
SAP-ABAP：SAP表与视图权限管控方案：表维护权限、视图访问权限配置实操
baidu_35680696的博客
06-15 757
SAP表与视图权限管控方案摘要 本文详细介绍了SAP系统中表和视图的三层级权限管控方案： 表维护生成器权限：通过配置权限组实现基础访问控制，支持自定义权限对象（SU21）进行细粒度管控 SM30事务码权限：利用权限对象S_TABU_DIS控制表维护操作，可在PFCG中配置角色实现权限细分 CDS视图DCL权限：通过访问控制定义实现记录级权限过滤，支持基于权限对象的动态数据访问控制 文章提供了完整的配置流程和ABAP代码示例，涵盖权限组创建、DCL语法、权限校验等关键操作，帮助企业构建安全的数据访问体系，满足
SpringMVC 入门到实战 RESTFul 49-55
道友
06-16 616
SpringMVC 入门到实战 RESTFul 49-55
MyBatis-Plus 完整实际使用整理
m0_73837751的博客
06-18 179
数据库操作方式总览│├── 方式一：BaseMapper + Wrapper（大厂主流）│ ├── 基础 CRUD：selectById / insert / updateById / deleteById│ ├── 条件操作：selectList(LambdaQueryWrapper) / delete(wrapper) ...│ ├── 分页：selectPage(IPage, wrapper) + 分页插件。
Java数据库连接池学习
u011237796的博客
06-18 210
表示并发情况下最大可从连接池中获取的连接数。连接池基本的思想是在系统初始化的时候，将数据库连接作为对象存储在内存中，当用户需要访问数据库时，并非建立一个新的连接，而是从连接池中取出一个已建立的空闲连接对象。maxIdle对应的连接，实际上是连接池保持的长连接，这也是连接池发挥优势的部分，理论上讲保持较多的长连接，在应用请求时可以更快的响应，但是过多的连接保持，反而会消耗数据库大量的资源，因此maxIdle也并不是越大越好，同上例我们建议将 maxIdle设置成50-100中靠近50的数字，例如55。
Spring AI Alibaba Agent 流式输出与 outputKey 完全指南
路过君的博客
06-15 1027
摘要 本文深入解析Spring AI Alibaba Agent的两个核心问题：流式输出处理和outputKey机制。针对agent.stream()的流式响应，文章提出三种提取最终回复的方案：1）使用AtomicReference在onComplete时获取完整状态；2）直接监听AGENT_MODEL_FINISHED事件获取最终结果；3）利用outputKey简化数据提取。特别强调在多Agent协作中，outputKey作为数据传递桥梁的关键作用。通过源码分析和实践示例，为开发者提供完整的流式输出处理指
Java 程序员第 43 阶段05：微服务整合大模型，跨服务调用架构设计实战，Seata分布式事务实战
fuleigang的专栏
06-15 1305
第一阶段：分支事务执行SQL，Seata解析SQL获取表结构，生成数据镜像（before image），执行SQL获取数据变化，生成数据镜像（after image），将前后镜像和SQL信息注册到TC。本章深入探讨了Seata分布式事务的实战应用，从四种事务模式的原理机制出发，详细讲解了AT、TCC、SAGA和XA模式的工作原理和适用场景。Seata通过XID（全局事务ID）串联各个分支事务，每个参与服务的每次SQL执行都会被Seata代理，自动记录前后镜像数据，实现无侵入式的分布式事务管理。
JUC 总结：从 Java 内存模型到线程池的并发核心梳理
2301_80821045的博客
06-15 595
本文总结了Java并发编程（JUC）的基础知识要点： 进程与线程：进程是资源分配的最小单位，线程是调度的最小单位，线程更轻量级且切换成本低； 线程创建方式：继承Thread类、实现Runnable/Callable接口、使用线程池（推荐）； Runnable与Callable区别：Callable有返回值且可抛异常，需通过FutureTask适配； 线程状态：新建、可运行、阻塞、等待、定时等待和终止6种状态； 线程控制：start()启动新线程，run()同步执行；join()实现顺序执行，CountDow
【Java项目技术亮点】Saga模式长事务编排
我是一颗柠檬的博客
06-21 391
本文介绍了Saga模式在分布式长事务处理中的应用，对比了TCC与Saga的优缺点。Saga通过正向操作和补偿操作实现最终一致性，适用于电商下单等跨多个服务的场景。文章详细解析了编排式和协同式两种Saga实现方式，并提供了Seata Saga的状态机配置示例和Java代码实现。Saga相比TCC具有代码侵入性低、维护成本低的优势，是处理长流程事务的更优解。
Spring Boot 基础：自动装配原理与 @EnableXXX 详解
weixin_44551234的博客
06-17 377
理解了以上模式后，开发者也可以编写自己的@Enable注解。@Bean使用时只需要在主类上加上即可。本文系统地拆解了 Spring Boot 自动装配原理与@EnableXXX中的通过@Import导入。利用加载中预定义的自动配置类，并通过条件注解筛选。被筛选出的配置类会像普通一样被解析，其中的@Bean方法会为容器提供默认基础设施。@EnableXXX注解普遍基于@Import，可导入配置类、或，实现特定功能的模块化开关。
【leetcode】121.买卖股票的最佳时机js/c++
2402_83244812的博客
06-16 392
摘要：该问题采用贪心算法解决股票买卖最佳时机问题。通过维护当前最小买入价和计算当前卖出利润，更新最大利润值。JavaScript实现遍历数组时动态更新最小价格和最大利润。类似地，C++版本使用迭代器跟踪买入点和遍历卖出点，当发现更低价格时更新买入点，并始终记录最大利润值。两种实现均只需一次遍历，时间复杂度为O(n)。
使用实时调度策略和无锁队列踩坑记录
weixin_38184628的博客
06-15 242
那么我们想一种场景，有3个线程，t1、t2、t3，t1的调度策略为SCHED_FIFO、优先级为1，t2的调度策略为SCHED_FIFO、优先级为2，t3的调度策略为SCHED_NORMAL，那么t2优先于t1被调度，t1优先于t3被调度。而实时调度策略，优先级高的又比优先级低的线程被优先调度。一般情况下，我们会认为try_push中会判断有没有剩余空间来盛放新的元素，如果有，那么就push成功，如果没有就通过返回值来标记，没有空间了，push失败，线程并不会在try_push内部陷入死循环；
[LangChain&LangGraph]. LangChain和LangGraph介绍
最新发布
Boop_wu的博客
06-21 567
模型切换成本高（耦合性）：一旦选定某个模型，代码往往与该模型的 API 强耦合。更换模型几乎等同于重写代码，缺乏灵活性非结构化输出难以解析（格式问题）：程序需要结构化数据（如 JSON）来驱动 UI 或逻辑，但 LLM 倾向于生成自然文本。强行用正则表达式提取不仅脆弱且易出错知识滞后与幻觉（时效性与准确性）：模型训练数据有截止日期（例如不知道最新的病毒变种），且可能产生“幻觉”。在医疗等严谨领域，必须结合外部实时数据或权威数据库。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

Qiye's Bolg

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

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

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

打赏作者

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

抵扣说明：

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

余额充值