jvm 垃圾收集器（ZGC）

最新推荐文章于 2024-08-18 21:34:58 发布
最新推荐文章于 2024-08-18 21:34:58 发布
阅读量1.8k 收藏 1
点赞数
分类专栏： java 虚拟机
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43931625/article/details/105111210
版权

jvm 垃圾收集器（ZGC）

 

官网：https://docs.oracle.com/en/java/javase/15/gctuning/z-garbage-collector.html#GUID-8637B158-4F35-4E2D-8E7B-9DAEF15BB3CD

 

 

*****************************

ZGC 简介

 

The Z Garbage Collector (ZGC) is a scalable low latency garbage collector. 
ZGC performs all expensive work concurrently, without stopping the execution of application 
threads for more than a few milliseconds. 

It is suitable for applications which require low latency. 
Pause times are independent of heap size that is being used. 
ZGC supports heap sizes from 8MB to 16TB.

低延时：所有耗时的工作都是并发执行，用户线程停顿时间很少

停顿时间可控：用户线程停顿时间与回收的堆大小无关

回收空间大：可回收16TB大小的堆空间

 

 

*****************************

ZGC 内存布局

 

将内存划分为多个region，（暂时）不设分代；使用整理算法对内存进行回收

      

ZGC的region可以动态的创建和销毁，并且region的大小可以动态变更，主要分三类：

小型region：固定为2M，用于存储小于256KB的小对象；

中型region：固定为4M，用于存储大于等于256KB，小于4M的对象；

大型region：大小可变化，需为2M的整数倍，存储大于等于4M的对象，大型region最小为4M

 

整理算法实现：读屏障、染色指针、内存多重映射

 

 

*****************************

内存多重映射：多个虚拟内存对应同一块物理内存

 

      

concurrent reloate阶段，重分配集（relocation set）中region的存活对象会复制到其他region中；

存活对象复制完成后，该region就可重新利用，可将这部分内存空间分配给新的对象；

此时，原对象的引用关系可能仍指向该内存地址（concurrent remap阶段会通过转发表修改为真实的内存地址），因此形成虚拟地址与物理地址多对一的关系

 

 

*****************************

染色指针、读屏障

 

      

ZGC的并发整理算法通过染色指针来实现

标记信息存储在引用对象的指针上：高18位不能使用，4位用来存储标记信息，低42位存储对象地址

染色指针不支持32位平台、不支持压缩指针（-XX:+UseCompressedOops）、最多可使用4TB（2的42次方）的物理内存

 

*********************

标志位说明

 

Marked0 /Marked1：标记位，标记对象是否可用

Remapped：记录对象是否进入过重分配集（对象是否移动过）

Finalizable：标记对象是否只能通过fnalize()访问

 

使用两个标记位Marked0、Marked1：在不同的回收周期交替使用，上一回收周期的标志位在本周期失效，重置为0

如：一个周期中使用Marked0，存活对象标记为01，

则下一个周期使用标记位Marked1，存活对象标记为10

 

 

*********************

优势

 

region上的存活对象都移走后就可回收region，不用等待引用关系都修改后再释放（引用关系修改通过转发表维护）；

染色指针使用读屏障修改引用关系，与使用写屏障相比，大幅减少内存屏障的使用数量；

可以开发未使用的18位记录标记、重定位等信息，将ZGC支持的堆内存由4TB拓展位128TB

 

 

*****************************

ZGC 回收过程

 

      

并发标记：Concurrent Mark

并发标记开始前，停止用户线程，枚举根节点；

并发标记期间，用户可以运行，根据根节点进行可达性分析并标记；

并发标记结束后，停止用户线程，做最终标记；

 

并发预重分配：Concurrent Prepare for relocate

扫描整个堆，找出需要清理的region，将这些region组成重分配集（relocation set）；

java12开始支持的类卸载、弱引用的删除也在这个阶段完成

 

并发重分配：Conurrent relocate

将重分配集中的region存活对象复制到其他region中，使用转发表维护旧对象与新对象的对应关系；

region中的存活对象全部复制完成后，该region的内存空间就可重新使用；

转发表不能释放，需要等到后续阶段对象的引用关系修改完成后才能删除

 

并发重映射：Concurrent Remap

根据转发表，修改指针指向：指向旧对象的内存地址修改为指向新对象的内存地址；

这一阶段的工作不一定要立刻完成的，zgc的实现是在下一阶段的Concurrent Mark阶段修改指针的内存地址

 

 

*****************************

相关参数

 

-XX:+UseZGC：使用zgc垃圾收集器（ZGC垃圾收集器在 java 15正式发布）

-XX:ConcGCThreads：垃圾回收线程数，ZGC会根据当前cpu自动设置

 

 

*****************************

示例

 

public class Test8 {

    public static void main(String[] args){
        byte[] b=new byte[10];
        b=null;

        System.gc();
    }
}

 

*********************

虚拟机参数

 

-Xms20m -Xmx20m -Xlog:gc* -XX:+UseZGC

 

*********************

控制台输出

 

[0.032s][info][gc,init] Initializing The Z Garbage Collector
[0.032s][info][gc,init] Version: 14+36-1461 (release)
[0.033s][info][gc,init] NUMA Support: Disabled
[0.033s][info][gc,init] CPUs: 8 total, 8 available
[0.033s][info][gc,init] Memory: 8079M
[0.033s][info][gc,init] Large Page Support: Disabled
[0.033s][info][gc,init] Medium Page Size: N/A
[0.033s][info][gc,init] Workers: 1 parallel, 1 concurrent
[0.034s][info][gc,init] Address Space Type: Contiguous/Unrestricted/Complete
[0.034s][info][gc,init] Address Space Size: 320M x 3 = 960M
[0.034s][info][gc,init] Min Capacity: 20M
[0.034s][info][gc,init] Initial Capacity: 20M
[0.034s][info][gc,init] Max Capacity: 20M
[0.034s][info][gc,init] Max Reserve: 2M
[0.034s][info][gc,init] Pre-touch: Disabled
[0.035s][info][gc,init] Uncommit: Disabled
[0.051s][info][gc,init] Runtime Workers: 1 parallel
[0.051s][info][gc     ] Using The Z Garbage Collector
[0.227s][info][gc,start] GC(0) Garbage Collection (Warmup)
[0.228s][info][gc,phases] GC(0) Pause Mark Start 0.558ms
[0.233s][info][gc,phases] GC(0) Concurrent Mark 5.530ms
[0.234s][info][gc,phases] GC(0) Pause Mark End 0.084ms
[0.234s][info][gc,phases] GC(0) Concurrent Process Non-Strong References 0.589ms
[0.234s][info][gc,phases] GC(0) Concurrent Reset Relocation Set 0.001ms
[0.248s][info][gc,phases] GC(0) Concurrent Select Relocation Set 13.698ms
[0.249s][info][gc,phases] GC(0) Pause Relocate Start 0.425ms
[0.253s][info][gc,phases] GC(0) Concurrent Relocate 3.846ms
[0.253s][info][gc,load  ] GC(0) Load: 0.00/0.00/0.00
[0.253s][info][gc,mmu   ] GC(0) MMU: 2ms/72.1%, 5ms/88.8%, 10ms/93.6%, 20ms/96.8%, 50ms/97.9%, 100ms/98.9%
[0.253s][info][gc,marking] GC(0) Mark: 1 stripe(s), 2 proactive flush(es), 1 terminate flush(es), 1 completion(s), 0 continuation(s) 
[0.253s][info][gc,reloc  ] GC(0) Relocation: Successful, 1M relocated
[0.253s][info][gc,nmethod] GC(0) NMethods: 178 registered, 0 unregistered
[0.253s][info][gc,metaspace] GC(0) Metaspace: 5M used, 5M capacity, 5M committed, 8M reserved
[0.253s][info][gc,ref      ] GC(0) Soft: 36 encountered, 0 discovered, 0 enqueued
[0.253s][info][gc,ref      ] GC(0) Weak: 99 encountered, 92 discovered, 17 enqueued
[0.253s][info][gc,ref      ] GC(0) Final: 0 encountered, 0 discovered, 0 enqueued
[0.253s][info][gc,ref      ] GC(0) Phantom: 14 encountered, 14 discovered, 13 enqueued
[0.253s][info][gc,heap     ] GC(0) Min Capacity: 20M(100%)
[0.253s][info][gc,heap     ] GC(0) Max Capacity: 20M(100%)
[0.253s][info][gc,heap     ] GC(0) Soft Max Capacity: 20M(100%)
[0.253s][info][gc,heap     ] GC(0)                Mark Start          Mark End        Relocate Start      Relocate End           High               Low         
[0.253s][info][gc,heap     ] GC(0)  Capacity:       20M (100%)         20M (100%)         20M (100%)         20M (100%)         20M (100%)         20M (100%)   
[0.253s][info][gc,heap     ] GC(0)   Reserve:        2M (10%)           2M (10%)           2M (10%)           2M (10%)           2M (10%)           2M (10%)    
[0.253s][info][gc,heap     ] GC(0)      Free:       14M (70%)          12M (60%)          12M (60%)          14M (70%)          14M (70%)          10M (50%)    
[0.253s][info][gc,heap     ] GC(0)      Used:        4M (20%)           6M (30%)           6M (30%)           4M (20%)           8M (40%)           4M (20%)    
[0.253s][info][gc,heap     ] GC(0)      Live:         -                 1M (6%)            1M (6%)            1M (6%)             -                  -          
[0.253s][info][gc,heap     ] GC(0) Allocated:         -                 2M (10%)           2M (10%)           4M (20%)            -                  -          
[0.254s][info][gc,heap     ] GC(0)   Garbage:         -                 2M (14%)           2M (14%)           0M (4%)             -                  -          
[0.254s][info][gc,heap     ] GC(0) Reclaimed:         -                  -                 0M (0%)            2M (10%)            -                  -          
[0.254s][info][gc          ] GC(0) Garbage Collection (Warmup) 4M(20%)->4M(20%)
[0.294s][info][gc,start    ] GC(1) Garbage Collection (System.gc())
[0.295s][info][gc,phases   ] GC(1) Pause Mark Start 0.491ms
[0.302s][info][gc,phases   ] GC(1) Concurrent Mark 6.725ms
[0.302s][info][gc,phases   ] GC(1) Pause Mark End 0.036ms
[0.303s][info][gc,phases   ] GC(1) Concurrent Process Non-Strong References 0.723ms
[0.303s][info][gc,phases   ] GC(1) Concurrent Reset Relocation Set 0.003ms
[0.305s][info][gc,phases   ] GC(1) Concurrent Select Relocation Set 2.693ms
[0.306s][info][gc,phases   ] GC(1) Pause Relocate Start 0.347ms
[0.310s][info][gc,phases   ] GC(1) Concurrent Relocate 3.839ms
[0.310s][info][gc,load     ] GC(1) Load: 0.00/0.00/0.00
[0.310s][info][gc,mmu      ] GC(1) MMU: 2ms/72.1%, 5ms/88.8%, 10ms/93.6%, 20ms/95.6%, 50ms/97.9%, 100ms/98.1%
[0.310s][info][gc,marking  ] GC(1) Mark: 1 stripe(s), 2 proactive flush(es), 1 terminate flush(es), 0 completion(s), 0 continuation(s) 
[0.310s][info][gc,reloc    ] GC(1) Relocation: Successful, 1M relocated
[0.310s][info][gc,nmethod  ] GC(1) NMethods: 199 registered, 0 unregistered
[0.310s][info][gc,metaspace] GC(1) Metaspace: 6M used, 6M capacity, 6M committed, 8M reserved
[0.310s][info][gc,ref      ] GC(1) Soft: 40 encountered, 0 discovered, 0 enqueued
[0.310s][info][gc,ref      ] GC(1) Weak: 89 encountered, 78 discovered, 1 enqueued
[0.310s][info][gc,ref      ] GC(1) Final: 0 encountered, 0 discovered, 0 enqueued
[0.310s][info][gc,ref      ] GC(1) Phantom: 5 encountered, 3 discovered, 0 enqueued
[0.310s][info][gc,heap     ] GC(1) Min Capacity: 20M(100%)
[0.310s][info][gc,heap     ] GC(1) Max Capacity: 20M(100%)
[0.310s][info][gc,heap     ] GC(1) Soft Max Capacity: 20M(100%)
[0.310s][info][gc,heap     ] GC(1)                Mark Start          Mark End        Relocate Start      Relocate End           High               Low         
[0.310s][info][gc,heap     ] GC(1)  Capacity:       20M (100%)         20M (100%)         20M (100%)         20M (100%)         20M (100%)         20M (100%)   
[0.310s][info][gc,heap     ] GC(1)   Reserve:        2M (10%)           2M (10%)           2M (10%)           2M (10%)           2M (10%)           2M (10%)    
[0.310s][info][gc,heap     ] GC(1)      Free:       14M (70%)          12M (60%)          12M (60%)          14M (70%)          14M (70%)          10M (50%)    
[0.310s][info][gc,heap     ] GC(1)      Used:        4M (20%)           6M (30%)           6M (30%)           4M (20%)           8M (40%)           4M (20%)    
[0.310s][info][gc,heap     ] GC(1)      Live:         -                 1M (6%)            1M (6%)            1M (6%)             -                  -          
[0.310s][info][gc,heap     ] GC(1) Allocated:         -                 2M (10%)           2M (10%)           4M (20%)            -                  -          
[0.310s][info][gc,heap     ] GC(1)   Garbage:         -                 2M (14%)           2M (14%)           0M (4%)             -                  -          
[0.310s][info][gc,heap     ] GC(1) Reclaimed:         -                  -                 0M (0%)            2M (10%)            -                  -          
[0.310s][info][gc          ] GC(1) Garbage Collection (System.gc()) 4M(20%)->4M(20%)
[0.313s][info][gc,heap,exit] Heap
[0.313s][info][gc,heap,exit]  ZHeap           used 4M, capacity 20M, max capacity 20M
[0.313s][info][gc,heap,exit]  Metaspace       used 6415K, capacity 6463K, committed 6656K, reserved 8192K

 

 

o_瓜田李下_o
关注
专栏目录
ZGC垃圾回收器
Waiting_Mr_Liu的博客
12-10 695
8.5.5. ZGC垃圾回收器 1）ZGC的介绍 ZGC垃圾回收器全称为Z Garbage Collector，是一个可伸缩的、低延迟、并发的垃圾收集器，主要为了满足如下目标进行设计： 1.停顿时间不会超过10ms 2.停顿时间不会随着堆的增大而增大（不管多大的堆都能保持在10ms以下） 3.可支持几百M，甚至几T的堆大小（最大支持4T） 2）ZGC的停顿时间 停顿时间在10ms以下，10ms其实是一个很保守的数据，在SPECjbb 2015基准测试，128G的大堆下最大停顿时间才1.68ms，远低于10m
JVM垃圾收集器 ZGC
weixin_43874650的博客
09-27 49
假如ZGC全过程需要执行10分钟，在这个期间由于对象分配速率很高，将创建大量的新对象，这些对象很难进入当次GC，所以只能在下次GC的时候进行回收，这些只能等到下次GC才能回收的对象就是浮动垃圾。安全点就是指代码中一些特定的位置,当线程运行到这些位置时它的状态是确定的,这样JVM就可以安全的进行一些操作,比如GC等，所以GC不是想什么时候做就立即触发的，是需要等待所有线程运行到安全点后才能触发。也就是说，几十G堆的停顿时间是10ms以下，几百G甚至上T堆的停顿时间也是10ms以下。
深入理解JVM - ZGC垃圾收集器
xiaolyuh的专栏
01-13 6072
如果下面的一些概念有些不清楚的可以先看深入理解JVM - 垃圾收集器和深入理解JVM - Shenandoah垃圾收集器。 ZGC（Z Garbage Collector）是一款由Oracle公司研发的，以低延迟为首要目标的一款垃圾收集器。它是基于动态Region内存布局，（暂时）不设年龄分代，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的收集器。在JDK 11新加入，还...
Java面试题--JVM大厂篇之解密ZGC：让你的Java应用高效飞驰
最新发布
青云交的博客
08-18 997
垃圾回收（GC）作为JVM的核心机制之一，其效率直接关系到应用的稳定性和响应速度。ZGC作为JVM的一项革命性技术，通过其高效的并发标记和重定位机制，显著减少了GC停顿时间，提升了应用的整体性能。在大型Java应用中，合理配置和调优ZGC，将带来显著的性能优化效果。希望通过本文的介绍和实战案例分享，能帮助你深入理解和应用ZGC，实现你的应用性能的突破。欢迎在评论区分享你的调优经验和问题，让我们共同进步，成为Java性能优化的专家！通过启用ZGC，并进行相关参数配置，我们可以显著优化该电商平台的性能。
jvm低延迟垃圾收集器（ZGC）
qq_26855461的博客
07-16 465
出入：深入理解Java虚拟机：JVM高级特性与最佳实践（第3版） ZGC全称Z Garbage Collector，是一款在JDK 11中新加入的具有实验性质的低延迟垃圾收集器，是由Oracle公司研发的。2018年Oracle创建了JEP 333将ZGC提交给OpenJDK，推动其进入OpenJDK 11的发布清单之中。 ZGC下一个这样的定义来概括它的主要特征：ZGC收集器是一款基于Region内存布局的，（暂时）不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低
Jvm之ZGC垃圾收集器
meser88的博客
04-03 455
ZGC（The Z Garbage Collector）是JDK 11中推出的一款追求极致低延迟的实验性质的垃圾收集器。对于Java项目而言，JVM进行垃圾回收总是绕不开一个问题，那就是Stop The World。对于很多大型项目或对响应时间有要求的项目，垃圾回收的停顿时间就是一个痛点，而ZGC就是一款低延迟的垃圾收集器。
JVM 从入门到放弃之 ZGC 垃圾收集器精讲
m0_49496327的博客
04-19 624
Z Garbage Collector，也称为ZGC，在 jdk 11 中引入的一种可扩展的低延迟垃圾收集器，在 jdk 15 中发布稳定版。在旨在满足以下目标： < 1ms 最大暂停时间(jdk < 16 是 10ms，jdk >=16 是 <1ms )。 暂停时间不会随着堆、live-set 或 root-set 的大小而增加。 使用内存大小从 8MB 到16TB 地堆。 ZGC 具有以下特征： 并发 基于 region 压缩 NUMA 感知 使用彩色指针
ZGC 简介：低延迟 JVM 垃圾收集器
DevCampsite的博客
10-03 792
ZGC 简介：低延迟 JVM 垃圾收集器
JVM垃圾收集器全面详解
03-17
Java虚拟机（JVM）是Java程序运行的基础，它的核心组成部分之一就是垃圾收集器（Garbage Collector, GC）。本文将全面解析JVM中的七种垃圾收集器，分析它们的特性和适用场景，帮助开发者理解如何优化Java应用的内存...
一文了解JVM全部垃圾回收器，从Serial到ZGC
02-24
对象搜索算法与回收算法介绍了垃圾回收的基础算法，相当于垃圾回收的方法论。...ZGC是目前JDK11的实验收集器。下面来看看各个收集器的特性Serial，是单线程执行垃圾回收的。当需要执行垃圾回收时，程序会暂停一切手上的
JVM 中的 ZGC 垃圾收集器
weixin_62421895的博客
07-29 368
本文主要是从概念上描述了ZGC的特征和工作过程。目前大多数互联网公司还是使用jdk8、jdk11主流使用的还是ParNew+CMS组合或者G1。对于我们一线Java开发者应该具备新技术的学习热情和关注度，才能在激烈的社会竞争中保持优势。httpshttpshttpshttpshttpshttpshttpshttps。...
JVM — JDK11垃圾回收器 ZGC
qq_38658567的博客
07-06 2899
ZGC（The Z Garbage Collector）是 JDK 11 中推出的一款低延迟垃圾回收器，为实现以下几个目标而诞生的垃圾回收器，停顿时间不超过 10ms，停顿时间不会因堆变大而变长，支持 8MB~4TB 级别的堆（未来支持 16TB）ZGC 作为下一代垃圾回收器，性能非常优秀。ZGC 垃圾回收过程几乎全部是并发，实际 STW 停顿时间极短，不到 10ms。这得益于其采用的着色指针和读屏障技术。
JVM垃圾回收——ZGC垃圾收集器
weixin_39555954的博客
04-02 3829
ZGC(Z Garbage Collector)是一款在jdk11中加入的具有实验性质的低延迟的垃圾收集器，在jdk15中去掉实验的标识，成为具有商用的垃圾收集器。垃圾收集停顿时间控制在10毫秒以内（在jdk16之后停顿时间已经控制到1毫秒以内）的一款低停顿的垃圾收集器。如果非要给ZGC下一个定义的话，ZGC收集器是一款基于Region内存布局的，不设分代（不分老年代、新生代）的，使用了等技术来实现的基于标记-整理算法实现的，以低延迟为首要目标的一款的垃圾收集器。
JVM垃圾收集器ZGC
怀素的专栏
12-19 436
Java11已经推出最新垃圾收集器，ZGC主要为了减少JVM停顿时间。阿里双十一已经在项目中使用ZGC，并且取得不错战绩。支持大内存使用，所以只支持64位系统。 ZGC全称是Z Garbage Collector，是一款可伸缩(scalable)的低延迟(low latency garbage)、并发(concurrent)垃圾回收器，旨在实现以下几个目标： 停顿时间不超过10ms 停顿时间...
JVM垃圾回收器之ZGC收集器
xuspCSDN的博客
11-28 287
一款在 JDK 11中新加入的具有实验性质的低延迟垃圾收集器
ZGC 垃圾回收器
程序猿进阶
04-11 1512
ZGC（The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器，它的设计目标包括： 【1】停顿时间不超过10ms； 【2】停顿时间不会随着堆的大小，或者活跃对象的大小而增加，影响它的是 GCRoot对象； 【3】支持 8MB~4TB级别的堆（未来支持16TB）； 从设计目标来看，ZGC适用于大内存低延迟服务的内存管理和回收。本文主要介绍 ZGC在低延时场景中的应用和卓越表现，文章内容主要分为四部分： 【1】GC之痛：介绍实际业务中遇到的 GC痛点，并分析 CMS收集器和
JVM-垃圾收集器ZGC浅析
玄霄
05-09 366
垃圾收集器ZGCZGC收集器ZGC设计目标不分代ZGC内存布局NUMA-aware颜色指针读屏障ZGC运作过程ZGC触发时机 ZGC收集器 ZGC是JDK11新加入的低延迟垃圾收集器。 ZGC设计目标 支持TB级别的堆 很少有上TB的硬盘，未来十年内ZGC够用了； 最大GC停顿时间不超过10ms 主要是因为他的停顿时间主要和GCRoot有关，和堆大小无关 奠定未来GC特性的基础 最糟糕情况下吞吐量降低15% 不分代 单代，即ZGC不存在年轻代和老年代的区分。 先实现一个简单可用的版本，后续可能会分代；
Java垃圾回收器：ZGC
m0_51720696的博客
08-31 259
1.ZGC简介 1.JDK11推出的低延迟垃圾回收器 2.支持4TB级别的堆 3.停顿不超过10ms，不随着堆增加而增加 2.垃圾回收器组合 1.Serial + SerialOld 2.PS：Parallel Scavenge +ParallelOld 3.CMS:ParNew + CMS 4.G1 ...
深入JVM垃圾回收器详解：ZGC，内存管理模型与高速分配设计
2401_83384536的博客
04-22 1301
2017年，Oracle公司宣布实现一款新的垃圾回收ZGC，并将贡献给OpenJDK社区。在2018年9月发布的JDK 11中，ZGC作为实验性质的特性被正式引入JVM中。自首次发布到目前为止，它是社区最活跃的项目。在随后的JDK12、JDK 13、JDK 14中都有重要的特性发布；在JDK 15中，ZGC正式升级为产品特性；ZGC的发展并没有停止，在JDK 16中引入了并发栈扫描，进一步减少停顿时间。在ZGC发布以前，JVM的所有垃圾回收器中对停顿时间管理得最好的是G1。
深入解析JVM七大垃圾回收器：从Serial到ZGC
本文将深入探讨Java虚拟机(JVM)中的垃圾回收器，从基础的Serial和ParNew收集器，到更高级别的ParallelScavenge、CMS、SerialOld、ParallelOld和G1，以及最新的实验性收集器ZGC。JVM采用分代收集策略，新生代和老年代...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值