JUC并发编程系列详解篇十二（synchronized底层原理进阶）

已于 2022-09-11 20:04:48 修改
阅读量584 收藏 1
点赞数
分类专栏： java基础 Java高级特性 并发编程 文章标签： jvm java 算法
于 2022-09-11 20:04:11 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_46198325/article/details/126801609
版权

通过对象头分析锁升级过程

可以通过对象头分析工具观察一下锁升级时对象头的变化：运行时对象头锁状态分析工具JOL，是OpenJDK开源工具包，引入下方maven依赖：

<dependencies>
        <dependency>
            <groupId>org.openjdk.jol</groupId>
            <artifactId>jol-core</artifactId>
            <version>0.10</version>
        </dependency>
</dependencies>

观察无锁状态下的对象头【无锁状态】：

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedTest01 {
    public static void main(String[] args) throws InterruptedException {
        Object object = new Object();
        System.out.println(ClassLayout.parseInstance(object).toPrintable());
    }
}

结果：

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           00 10 00 00 (00000000 00010000 00000000 00000000) (4096)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

这里先详细解释一下打印结果，后面就不做详细分析了：

  • OFFSET ： 内存地址偏移量
  • SIZE ： 本条信息对应的字节大小
  • Instance size: 16 bytes ：本次new出的Object对象的大小

由于当前所使用的的机器是64位操作系统的机器，所以前两行代表的就是对象头MarkWord，已经在上述运行结果中标出，刚好是8字节，每个字节8位，刚好是64位；由前文中32位对象头与64位对象头的位数对比可知，分析对象头锁升级情况看第一行的对象头即可。

第三行指的是类型指针（上文中有说过，指向的是方法区的类元信息），已经在上述运行结果中标出，Klass Pointer在64位机器默认是8字节，这里由于指针压缩的原因当前是4字节。

第四行指的是对齐填充，有的时候有有的时候没有，JVM内部需要保证对象大小是8个字节的整数倍，实际上计算机底层通过大量计算得出对象时8字节的整数倍可以提高对象存储的效率。

可以观察到本次new出的Object对象的大小实际只有12字节，这里对象填充为其填充了4个字节，就是为了让Object对象大小为16字节是8字节的整数倍。

JVM采用的是小端模式，需要现将其转换成大端模式，具体转换如下图所示：
在这里插入图片描述
可以看出一开始对象没有加锁，通过最后三位的“001”也能观察到，前25位代表hashcode，那这里为什么前25位是0呢？其实hashcode是通过C语言类似于“懒加载”的方式获取到的，所以看到该对象的高25位并没有hashcode。

观察有锁无竞争状态下的对象头【无锁->偏向锁】：

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedTest02 {
    public static void main(String[] args) throws InterruptedException {
        Object object = new Object();
        System.out.println(ClassLayout.parseInstance(object).toPrintable());
        synchronized (object){
            System.out.println(ClassLayout.parseInstance(object).toPrintable());
        }
    }
}

运行结果（JVM默认小端模式）：

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           90 39 62 05 (10010000 00111001 01100010 00000101) (90323344)
      4     4        (object header)                           00 70 00 00 (00000000 01110000 00000000 00000000) (28672)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

运行结果分析：

通过运行结果可以看到，先打印出来的是一个“001”无锁的状态，但是后打印出来的“000”并不是偏向锁的状态，查上面的表可以发现“000”直接就是轻量级锁的状态了。

JVM启动的时候内部实际上也是有很多个线程在执行synchronized，JVM就是为了避免无畏的锁升级过程（偏向锁->轻量级锁->重量级锁）带来的性能开销，所以JVM默认状态下会延迟启动偏向锁。

只要将代码前面加个延迟时间即可观察到偏向锁：

import org.openjdk.jol.info.ClassLayout;
import java.util.concurrent.TimeUnit;

public class SynchronizedTest02 {

    public static void main(String[] args) throws InterruptedException {
        TimeUnit.SECONDS.sleep(6);
        Object o = new Object();
        System.out.println(ClassLayout.parseInstance(o).toPrintable());
        synchronized (o){
            System.out.println(ClassLayout.parseInstance(o).toPrintable());
        }
    }
}

运行结果（JVM默认小端模式）：

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 90 80 de (00000101 10010000 10000000 11011110) (-561999867)
      4     4        (object header)                           b2 7f 00 00 (10110010 01111111 00000000 00000000) (32690)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

对未开启偏向锁与开启偏向锁的运行结果分析：

  1. 未开启偏向锁（大端模式），没加锁：00000000 00000000 00000000 00000001
  2. 开启偏向锁（大端模式），没加锁 ：00000000 00000000 00000000 00000101
  3. 开启偏向锁（大端模式），加锁 ：11011110 10000000 10010000 00000101

开启偏向锁之后的无锁状态，会加上一个偏向锁，叫匿名偏向（可偏向状态），表示该对象锁是可以加偏向锁的，从高23位的23个0可以看出暂时还没有偏向任何一个线程，代表已经做好了偏向的准备，就等着接下来的某个线程能拿到就直接利用CAS操作把线程id记录在高23位的位置。

观察有锁有竞争状态下的对象头【偏向锁->轻量级锁】：

import org.openjdk.jol.info.ClassLayout;

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

        Thread.sleep(5000);

        Object object = new Object();

        //main线程
        System.out.println(ClassLayout.parseInstance(object).toPrintable());

        //线程t1
        new Thread(() -> {
            synchronized (object) {
                System.out.println(ClassLayout.parseInstance(object).toPrintable());
            }
        },"t1").start();

        Thread.sleep(2000);

        //main线程
        System.out.println(ClassLayout.parseInstance(object).toPrintable());
        //线程t2
        new Thread(() -> {
            synchronized (object) {
                System.out.println(ClassLayout.parseInstance(object).toPrintable());
            }
        },"t2").start();
    }
}

运行结果（JVM默认小端模式）：

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)        //main线程打印
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 90 94 2d (00000101 10010000 10010100 00101101) (764710917)    //t1线程打印
      4     4        (object header)                           c9 7f 00 00 (11001001 01111111 00000000 00000000) (32713)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 90 94 2d (00000101 10010000 10010100 00101101) (764710917)     //main线程打印
      4     4        (object header)                           c9 7f 00 00 (11001001 01111111 00000000 00000000) (32713)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           08 a9 d5 07 (00001000 10101001 11010101 00000111) (131442952)    //t2线程打印
      4     4        (object header)                           00 70 00 00 (00000000 01110000 00000000 00000000) (28672)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

运行结果分析：
一开始main线程打印出的object对象头可以看出是匿名偏向；

接着线程t1打印了object对象头，可以与第一个打印出来的对象头对比不难发现t1打印的也是偏向锁，但是t1打印的对象头已经把t1的线程id记录在了其对应的23位；

程序再次回到main线程，其还是打印出来刚刚t1的对象头数据，也就是说偏向锁一旦偏向了某个线程后，如果线程不能重新偏向的话，那么这个偏向锁还是会一直记录着之前偏向的那个线程的对象头状态；

接着线程t2又开始打印了object对象头，可以看出最后一次打印已经升级成了轻量级锁，因为这里已经存在两个线程t1、t2交替进入了object对象锁的同步代码块，并且锁的不激烈竞争，所以锁已经升级成了轻量级锁。

观察无锁升级成重量级锁状态下的对象头的整个过程【无锁->重量级锁】：

import org.openjdk.jol.info.ClassLayout;

public class SynchronizedTest04 {
    public static void main(String[] args) throws InterruptedException {
        Thread.sleep(5000);
        Object object = new Object();

        System.out.println(ClassLayout.parseInstance(object).toPrintable());

        new Thread(()->{
            synchronized (object) {
                System.out.println(ClassLayout.parseInstance(object).toPrintable());
                //延长锁的释放，造成锁的竞争
                try {
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        },"t0").start();

        Thread.sleep(5000);

        new Thread(() -> {
            synchronized (object) {
                System.out.println(ClassLayout.parseInstance(object).toPrintable());
                //延长锁的释放，造成锁的竞争
                try {
                    Thread.sleep(5000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        },"t1").start();

        new Thread(() -> {
            synchronized (object) {
                System.out.println(ClassLayout.parseInstance(object).toPrintable());
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        },"t2").start();
    }
}

运行结果：

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 00 00 00 (00000101 00000000 00000000 00000000) (5)      //main线程打印
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           05 d8 8f ef (00000101 11011000 10001111 11101111) (-275785723)  //t0线程打印
      4     4        (object header)                           ce 7f 00 00 (11001110 01111111 00000000 00000000) (32718)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           00 e9 a9 09 (00000000 11101001 10101001 00001001) (162130176)  //t1线程打印
      4     4        (object header)                           ce 7f 00 00 (11001110 01111111 00000000 00000000) (32718)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           0a d8 80 f0 (00001010 11011000 10000000 11110000) (-259991542)  //t2线程打印
      4     4        (object header)                           ce 7f 00 00 (11001110 01111111 00000000 00000000) (32718)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

运行结果分析（JVM默认小端模式）：
程序一开始就是设置了5秒钟的睡眠，目的在于让JVM优先加载完成后，让JVM默认状态下会延迟启动偏向锁，可以开出一开始main线程打印的是“101”就是默认的匿名偏向锁，但是并没有设置线程id；之后t0线程就立马打印了，此时只需利用CAS操作把t0的线程id设置进对象头即可，所以这个时候也是一个偏向锁状态；之后的程序睡眠5秒钟后，程序中t1、t2线程执行代码块时，有意的将其线程睡眠几秒钟，目的在于不管那个线程率先抢到锁，都能让另外一个线程在自旋等待中，所以t1线程打印的是“00”就已经是轻量级锁了，最后看程序执行结果，t2打印的是“10”就已经升级为重量级锁了，显然t2线程已经超过了自旋的最大次数，已经转成重量级锁了。

参考文章

  • 微信公众号(得物技术) ：精选文章｜深入理解synchronzied底层原理
淡墨@～无痕
关注
专栏目录
Java并发编程（24）—— JUC并发编程类库详解
shangjg3的博客
09-03 222
CyclicBarrier 是一个同步辅助类，用于让一组线程到达一个屏障（barrier）时被阻塞，直到最后一个线程到达屏障时，屏障才会开门，所有被屏障拦截的线程才会继续运行。这意味着在修改操作发生时，会创建一个新的数组，并将现有的所有元素复制到新数组中，然后在新数组上进行修改。这意味着在修改操作发生时，会创建一个新的数组，然后将现有的所有元素复制到新数组中，并在新数组上进行修改。当一个线程到达交换点时，它会调用 exchange() 方法，该方法会尝试将该线程的数据与另一个线程的数据交换。
JUC并发编程（java.util .concurrent工具包）详解与实例演示
BaiKnow的博客
02-03 1653
JUC 并发编程 作者：pox21s 概述 在Java中，线程部分是一个重点，本篇文章说的是关于线程并发编程。JUC就是java.util .concurrent工具包的简称。这是一个处理线程的工具包，从JDK 1.5开始出现。 1.基本概念 1.1 进程和线程 1.1.1 定义 进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动，进程是系统进行资源分配和调度的一个基本单位。 线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位。线程自己基本上不拥
Java多线程——synchronized同步锁的原理深度解析以及多线程加锁优化
保暖透气大裤衩LeoLee的博客
12-01 494
Monitor 解释synchronized同步远离之前，首先了解一下Monitor（翻译为监视器，又叫管程，基于操作系统）。 首先明确的是每一个Java对象都可以关联一个Monitor对象，当使用synchronized关键字的时候，该对象就会与一个Monitor对象关联，即该对象的Mark word中就会设置一个只想Monitor对象的指针（一个普通的对象包含64 bits的Object head、32 bits的Mark word 以及32 bits的Klass word）。 重量级锁加锁原理
Synchronized关键字及锁升级
weixin_46217160的博客
09-26 456
Synchronized关键字
synchronized详解
rockvine的博客
07-18 3714
一、基本使用1.1、对象锁1.2、类锁二、原理解析2.1、对象头规范2.1.1、对象头内容2.1.2、对象头布局2.1.3、 大小端模式2.2、锁状态2.2.1、无锁2.2.2、偏向锁2.2.2.1、偏向锁加锁2.2.2.2、偏向锁升级2.2.2.3、批量重偏向2.2.2.4、批量撤销2.2.3、轻量锁2.2.3.1、轻量锁的加锁2.2.3.2、轻量锁的释放2.2.4、自旋锁2.2.4.1、适应性自旋2.2.5、重量锁2.3、锁升级一、基本使用synchronized是Java并发编程中的同步机制关键字，它
synchronized解析
热门推荐
意田天的博客
07-12 2万+
synchronized解析1. 用户态与内核态2. CAS3. UnsafeAtomicInteger解析4. 了解对象的内存布局（hotspot）1. 对象头2. 成员变量（实例数据）3. 对齐数据工具：JOL = Java Object Layout6. synchronized的横切面详解重量级锁java源码层级字节码层级JVM层级（Hotspot）7. 锁升级过程7.1 JDK8 markword实现表：7.2 锁重入7.3 synchronized最底层实现7.4 synchronized vs
Synchronized_源码级深度分析
weixin_36114346的博客
06-15 298
synchronized 、并发、线程安全、源码、hotspot
JUC并发编程系列详解篇十（Synchronized底层原理分析）
m0_46198325的博客
09-11 323
synchronized 锁机制在 Java 虚拟机中的同步是基于进入和退出监视器锁对象 monitor 实现的（无论是显示同步还是隐式同步都是如此），每个对象的对象头都关联着一个 monitor 对象，当一个 monitor 被某个线程持有后，它便处于锁定状态。
JUC并发编程.md
01-28
### JUC并发编程知识点 #### 一、JUC并发编程简介 JUC（Java Util Concurrency）是Java标准库中的一个子包，提供了一系列高级并发工具类和接口，旨在简化多线程编程的复杂性。它包括了各种锁机制、线程池、信号量...
java并发编程专题（五）----详解（JUC）ReentrantLock
08-18
Java并发编程中的ReentrantLock是Java并发包（java.util.concurrent，简称JUC）中的一个重要的锁机制，它是Lock接口的一个具体实现，提供了比synchronized更强大的锁定功能和更细粒度的控制。ReentrantLock的主要...
Java多线程进阶之JUC并发编程教程详解（狂神说学习笔记）
super_song的博客
05-01 1203
文章目录环境准备1.JUC 简介2.线程和进程线程和进行并发和并行线程的状态wait/sleep的区别3.Lock 锁（重点）Synchronized 传统的锁Lock锁synchronized 和 lock 锁的区别4.生产者和消费者问题Synchronized 版本JUC 版本5.八个有关锁的问题问题1：两个同步方法，先执行发短信还是打电话？问题2：如果发短信延迟2秒，谁先执行问题3 加上一个没有锁的普通方法，谁先执行问题4：两个对象，一个调用发短信，一个调用打电话，谁先执行问题5：原来的两个同步方法，
深入理解synchronized（一）——初识synchronized
weixin_44271683的博客
04-10 823
synchronized synchronized是java中的一个关键字，简单来说，synchronized关键字以同步方法和同步代码块的方式，为方法和代码块上的对象加锁。使得同一时刻，在这个对象上的多个线程，只能由持有这个对象锁的单个线程进行代码的调用执行，本文将介绍为什么要加锁以及synchronized的用法以及使用上的区别。 为什么要加锁？ 简单的说，加锁是为了避免多线程下并发冲突，锁是一种数据保护机制，可允许某一个线程（进程）进行操作锁，当文件锁上时，其他线程（进程）根据锁的性质（读写锁，阻塞非
JDK成长记16：从0分析你不知道的synchronized底层原理（下）
繁茂的博客
10-22 223
上一节你了解了什么是CAS、synchronized形成的锁的类型、重量级锁是用户态进程向内核态申请资源加锁过程，HotSpot Java对象结构，以及初步从3个层面分析了下synchronized的核心流程。还记得核心流程图么？ 如下所示： 这一节我们仔细来分析下这个过程中，每一步的底层原理。我们需要用到一个工具包，JOL，它可以将java对象的信息打印出来。你可以通过这个工具分析升级过程中锁的标记变化。 synchronized锁升级流程详解 synchronized锁升级流.
JUC学习笔记(二) synchronized 底层原理探究
slxysyka的博客
03-08 314
synchronized 底层原理探究，锁膨胀机制，对象存储结构，监视器对象结构，加锁和解锁流程，可重入性
【JVM】—深入理解ZGC回收器—关键技术详解
最新发布
一棵灬大树的博客
10-18 782
从ZGC的内存布局、着色指针和读屏障三个关键技术出发，详解解释ZGC性能高的原因
Golang笔记_day05
Runing_WoNiu的博客
10-12 899
​ 一.Golang 垃圾回收 回收算法：三色标记+混合写屏障 1.回收算法演变 Golang中的垃圾回收主要应用三色标记法，GC过程和其他用户goroutine可并发运行，但需要一定时间的**STW(stop the world)**，STW的过程中，CPU不执行用户代码，全部用于垃圾回收，这个过程的影响很大，Golang进行了多次的迭代优化来解决这个问题 Go V1.3之前的标记-清除(mark and sweep)算法 缺点： STW，stop the world；让程序暂停，
arthas常用命令（五）--heapdump 、jvm
一生编程，快乐编程
10-15 239
heapdump , 类似 jmap 命令的 heap dump 功能。arthas-output 是arthas 生成到项目中的文件。dump.hprof 是自定义的 dump 文件名称。
JVM进阶调优系列(4)年轻代和老年代采用什么GC算法回收?
拉丁解牛技术专栏
10-18 547
大厂面试真题:GC 算法有多少种？各自优缺点是什么？年轻代和年老代选择哪种算法最优？本文深入浅出剖析相关算法核心原理以及优缺点，并通过画图详细分析举例。
【JVM】—深入理解ZGC回收器—背景概念&回收流程
一棵灬大树的博客
10-18 642
ZGC初始化时会为堆分配内存，并将所有对象标记为“存活”状态。这个阶段主要识别哪些对象是不再使用的。ZGC使用了基于Card Table的追踪算法（G1中的CSet与RSet概念）来发现引用关系。标记过程是并发的，意味着它可以与应用程序的执行同时进行，以减少停顿时间。在这个过程中，ZGC会维护一个引用队列，用于跟踪新创建的对象或更新的引用。虽然ZGC的目标是最小化暂停时间，但仍然需要短暂的暂停来安全地重定位对象。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值