JVM调优思路

原创 于 2025-12-16 14:00:00 发布 · 560 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#jvm #jvm调优 #调优实战

JVM 调优思路（从“瞎调参数”到“可验证的工程方法”）

这份文档讲的是方法论 + 常见场景的落地步骤。JVM 调优不是背参数，而是：先测、再定位、再改、再验证。
默认以服务端 Java（Spring Boot / 微服务 / 容器）为主，兼顾 JDK8～JDK17 常见差异。

1. 先把“调优目标”说清楚（不然你永远在乱跑）

调优的目标通常就三类，选一个当主目标，别三心二意：

  1. 低延迟：P99/P999 响应时间稳定，GC 暂停可控
  2. 高吞吐：单位时间处理更多请求（允许一定暂停）
  3. 低成本：更少内存、更少 CPU、同样吞吐（尤其容器/云上）

经验：线上多数问题是“延迟毛刺”或“内存不可控”，吞吐反而不是第一位。

2. 调优的基本套路（强烈建议照这个来）

2.1 先做基线（Baseline）

你需要一组“现在”的数据，才能证明“你改完更好了”。至少要有：

  • 业务指标：QPS、P99、错误率、超时率
  • JVM 指标：GC 次数/暂停、堆使用、线程数、类加载数
  • 系统指标：CPU、Load、RSS、IO、网络

2.2 再定位“瓶颈类型”

JVM 调优常见瓶颈几乎都落在这几类：

  • GC 压力大（分配太快 / 回收太慢 / 老年代膨胀）
  • 堆外内存吃满（DirectBuffer / mmap / Netty）
  • 元空间泄漏（类加载器泄漏、动态代理生成太多类）
  • 线程太多（栈内存、上下文切换、锁竞争）
  • CPU 火焰图热点（对象创建过多、序列化、正则、JSON、反射等）

2.3 再做小步实验（一次只改一个点）

  • 一次改一个参数或一个代码点
  • 压测/回放同样的流量
  • 用同样的指标对比（别凭感觉）

3. 先把“证据”拿到：你需要哪些观测手段

3.1 必开：GC 日志（别调优还不让 JVM 说话）

  • JDK8 常用：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution
-XX:+PrintGCApplicationStoppedTime -Xloggc:/path/gc.log
  • JDK9+（推荐写法）：
-Xlog:gc*,safepoint:file=/path/gc.log:time,uptime,tags,level

GC 日志是调优的“黑匣子”。没有它，很多结论都是拍脑袋。

3.2 线上常用命令（不重启也能看很多）

  • 查看 JVM 参数/版本/命令行：
jcmd <pid> VM.version
jcmd <pid> VM.flags
jcmd <pid> VM.command_line
  • 查看堆/类/线程概况：
jcmd <pid> GC.heap_info
jcmd <pid> GC.class_stats
jcmd <pid> Thread.print
jstat -gcutil <pid> 1000
  • 生成 dump（高危操作：注意磁盘、会 STW）：
jcmd <pid> GC.heap_dump /tmp/heap.hprof
jcmd <pid> VM.native_memory summary   # 需要 -XX:NativeMemoryTracking=summary/detail

3.3 低开销性能分析（强烈推荐）

  • JFR（JDK11+ 非常好用）：看分配热点、锁、线程、GC、IO
  • async-profiler：火焰图定位 CPU 热点/分配热点
  • Arthas：临时看热点方法、线程阻塞、Trace 调用链

4. JVM 里“真影响线上”的几个内存块（别只盯着堆）

  • Java Heap（堆）：对象主要在这；你调的大部分参数都围绕它
  • Metaspace（元空间）：类元数据；类加载器泄漏会炸它
  • Thread Stack（线程栈）：线程多了就会占内存；-Xss 影响
  • Direct/Native（堆外）：Netty/NIO/ByteBuffer/mmap；OOM 不一定是堆 OOM
  • Code Cache：JIT 编译后的代码缓存，满了会退化性能

结论：你看到“机器内存快满了”，不代表堆满；也可能是堆外、线程、元空间。

5. 选择 GC：别迷信“最牛”，要看你的目标

5.1 常见选择（JDK 版本相关）

  • Parallel GC：吞吐强，暂停长（适合离线/批处理）
  • G1 GC：通用型，暂停可控（现代服务端默认主力）
  • ZGC / Shenandoah：超低暂停（延迟敏感、堆很大时很香，但看 JDK 版本支持）

如果你是常规 Spring Boot 微服务：优先 G1。
如果你是低延迟且堆很大：考虑 ZGC/Shenandoah（前提：JDK17+ 更稳）。

6. 调优最常见的“症状 -> 原因 -> 处理”

下面按线上最常见的几种痛点给出“排查路径 + 参数方向 + 代码方向”。

场景 A：Minor GC 很频繁，P99 抖动明显

症状

  • GC 日志里 Young GC（或 G1 的 Evacuation Pause）很密
  • CPU 有波动，吞吐受影响
  • jstat -gcutil 看 YGC 次数飞涨

常见原因

  • 对象分配速率太高（JSON、字符串拼接、List/Map 频繁创建）
  • 新生代太小，撑不住分配洪峰
  • 大对象直接进老年代（G1 的 humongous）

处理步骤

  1. 先算“分配速率”
    • 用 JFR/async-profiler 看 Allocation flamegraph
  2. 业务上减分配：复用 buffer、避免临时对象、优化序列化
  3. 参数上：扩大可用堆/新生代（优先保证整体堆合理）
    • JDK8（CMS/Parallel）时代常见：-Xms -Xmx 固定 + -XX:NewRatio
    • G1 时代不建议死抠 NewRatio，更建议给足堆、让 G1 自适应
  4. 如果是 humongous（大对象）：
    • 优化大数组/大字符串/大 ByteBuffer 的生命周期
    • 让大对象别频繁创建（比如把大响应做流式输出）

场景 B：Full GC / Mixed GC 很慢，卡顿明显

症状

  • 请求出现“秒级/十秒级”暂停
  • GC 日志出现 Full GC 或 G1 Mixed Pause 很长
  • 老年代占用长期高位

常见原因

  • 老年代真的装不下了（泄漏或缓存不受控）
  • 晋升过快（Survivor 放不住，直接进老年代）
  • Reference（Soft/Weak/Phantom）处理开销大
  • G1：Region 回收跟不上 / Humongous 多

处理步骤

  1. 判断是“泄漏”还是“业务峰值”
    • 堆使用曲线是否回不去？（回不去很像泄漏）
  2. Dump + 分析（MAT / YourKit / JProfiler）
    • 看 Dominator Tree、Top Consumers、GC Roots
  3. 如果不是泄漏：
    • 给足堆（最简单有效）
    • 调整 GC 目标（例如 G1 的 -XX:MaxGCPauseMillis 别设置得太激进）
  4. 如果是泄漏：
    • 修代码（缓存、静态集合、ThreadLocal、监听器、ClassLoader）
    • 绝大多数“调参数”救不了真正泄漏

场景 C：CPU 很高，但 GC 并不频繁

症状

  • CPU 常年 80%+，但 GC log 很平稳
  • QPS 上去后延迟爆炸

常见原因

  • 业务热点（序列化/反序列化、加解密、压缩、正则）
  • 锁竞争/线程切换（线程太多）
  • 线程池队列堆积导致上下游雪崩

处理步骤

  1. async-profiler 采 CPU 火焰图（最直接）
  2. 如果锁竞争：JFR 看 Monitor/Lock 事件
  3. JVM 参数通常不是主因，重点在：
    • 减少热点路径的对象创建与拷贝
    • 控制线程数，避免“堆线程解决一切”的幻觉
    • 让 IO 等待别变 CPU 忙等

场景 D：OOM 但堆没满（最容易误判）

典型报错

  • java.lang.OutOfMemoryError: Direct buffer memory
  • OutOfMemoryError: Metaspace
  • unable to create new native thread

处理思路

  • Direct OOM：看 Netty/NIO buffer；限制/监控 -XX:MaxDirectMemorySize
  • Metaspace OOM：检查动态生成类/反射代理；设置 -XX:MaxMetaspaceSize 只是止血
  • Native thread：线程数太多或 -Xss 太大；减少线程、调小栈

建议开启 NMT（需要重启）：

-XX:NativeMemoryTracking=summary

然后：

jcmd <pid> VM.native_memory summary

7. 一套“可抄作业”的调优检查清单

7.1 启动参数（通用基线）

  • 固定堆：减少动态扩容抖动
-Xms4g -Xmx4g
  • 记录崩溃信息、OOM 自动 dump（注意磁盘）
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp
-XX:ErrorFile=/tmp/hs_err_pid%p.log
  • 打开 GC 日志（JDK9+ 推荐）
-Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags

7.2 容器/K8s 必看（很多人死在这里）

在容器里，别继续用“按物理机内存”的老思路，建议使用百分比参数（JDK10+ 更友好）：

-XX:InitialRAMPercentage=50
-XX:MaxRAMPercentage=75

重点：容器内存限制太小，堆 + 堆外 + 线程栈 + 元空间 = 一起把 Pod 干掉。

8. G1 常用调参方向（别上来就堆一堆 flags）

你真的需要调 G1 参数的情况：

  • 你已经有 GC 日志和明确瓶颈
  • 你已经确认“加堆/修分配”解决不了

几个常见方向：

  • 目标暂停时间（别设太小，不然 G1 会很激进、吞吐掉）
-XX:MaxGCPauseMillis=200
  • 触发 Mixed 回收阈值（让老年代别拖太久）
-XX:InitiatingHeapOccupancyPercent=30
  • 并行/并发线程（通常交给 JVM 自己，除非你 CPU 很小或很大）
-XX:ParallelGCThreads=8
-XX:ConcGCThreads=2

经验：G1 最有效的“参数”经常不是参数，而是 给足堆 + 降低分配率。

9. 线上一次完整调优的“实战流程模板”

  1. 明确目标：比如 P99 < 200ms，Full GC 不能超过 200ms
  2. 开启/收集：GC 日志 + 指标（至少 1～3 天）
  3. 定位：
    • GC 问题？看暂停、频率、老年代趋势
    • CPU 问题？火焰图
    • 堆外问题？NMT/Direct 指标
  4. 提出假设：比如“分配率太高导致 YGC 频繁”
  5. 实验：
    • 先改代码（减少分配/减少大对象）
    • 再改参数（加堆、调 G1 阈值）
  6. 验证：压测/回放 + 对比基线
  7. 固化：把结论写进 runbook（别下次又从头踩坑）

10. 常见误区（踩了就会“越调越差”）

  • 只看堆，不看堆外/线程/元空间
  • GC 暂停长就疯狂调 MaxGCPauseMillis（会牺牲吞吐，甚至更抖）
  • 不做基线，改完只靠感觉
  • 一次改一堆参数，最后根本不知道哪个有效
  • 把泄漏当作“堆不够”（短期能活，长期必炸）
  • 容器里照搬物理机参数（OOMKilled + 还以为是 JVM 崩了）

11. 最小可用的“参数模板”（给你一个起点）

11.1 通用服务端（G1，JDK11/17）

-Xms4g -Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp
-Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags

11.2 延迟敏感（ZGC，JDK17+，需要验证）

-Xms4g -Xmx4g
-XX:+UseZGC
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp
-Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags

注意：不同 JDK 版本对 GC 实现和默认值差异很大，别跨版本硬抄 flags。

12. 快速自检：你现在到底该从哪里下手？

  • 你看到 P99 抖动 + GC 日志有长暂停 → 先看 GC 类型/暂停来源（Young/Mixed/Full）
  • 你看到内存涨到顶不回落 → 先怀疑泄漏（dump 分析），别先加堆
  • 你看到 CPU 常年高 → 火焰图先上，别先调 GC
  • 你看到 OOM 但堆不大 → 查 Direct/Metaspace/线程，别只看 -Xmx

13. 附：常用命令速查

# 进程
jps -l

# GC/堆概况
jstat -gcutil <pid> 1000
jcmd <pid> GC.heap_info

# 线程栈
jstack <pid> | head -200
jcmd <pid> Thread.print > /tmp/threaddump.txt

# 导出堆 dump（可能 STW）
jcmd <pid> GC.heap_dump /tmp/heap.hprof

# NMT（需要启动时开 -XX:NativeMemoryTracking=summary）
jcmd <pid> VM.native_memory summary
jvm调优思路
qq_24095055的博客
08-20 779
jhat(JVM Heap Analysis Tool)命令是与 jmap 搭配使用，用来分析 jmap 生成的 dump，jhat 内置了一个微型的 HTTP/HTML 服务器，生成 dump 的分析结果后，可以在浏览器中查看。线程快照是当前 java 虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。JDK监控和故障处理命令有。
JVM基本调优思路和步骤
rockabye_kk的博客
02-05 760
jvm调优相关
JVM调优思路分享
@峰的博客
03-08 662
每天100w次登陆请求, 8G 内存该如何设置JVM参数？ step1：新系统上线如何规划容量？ step2：该如何进行垃圾回收器的选择？ step3：如何对各个分区的比例、大小进行规划 step4：栈内存大小多少比较合适？ step5：对象年龄应该为多少才移动到老年代比较合适？ step6：多大的对象，可以直接到老年代比较合适？ step7：垃圾回收器CMS老年代的参数优化 step8：配置OOM时候的内存dump文件和GC日志 调优总结 什么是ZGC？ 如何选择垃圾收集器？
【JVM调优】如何进行JVM调优？一篇文章就够了！
热门推荐
种一棵树最好的时间是十年前，其次是现在
09-21 4万+
深入解读JVM性能的监控、定位和调优方案，阐述jps/stat/jstack、MAT等常用性能分析工具的使用，提出JVM参数、内存溢出、内存泄漏、CPU飙升、GC频繁等实际场景下JVM调优的方案。
JVM调优思路整理
大叶子不小的博客
09-23 1200
垃圾回收维度 （1）GC日志：停顿时间和吞吐量 停顿时间：垃圾收集器进行垃圾回收终端执行响应的时间 停顿时间小适用于 和用户交互比较多的场景 吞吐量：用户代码执行时间/（用户代码执行时间+垃圾收集时间） 用户代码运行占用CPU的时间较长，适合运算、跑后台任务的场景 根据业务和硬件对垃圾回收器分类 停顿时间比较小的收集器：CMS、G1适用于web应用 (并发类的收集器) 吞吐量有限：ParaOld Paralle Scanvent (并行类的收集器) 串行收集器：
java 的jvm调优思路
penggerhe的博客
04-26 366
JVM 调优是指通过对 JVM 的参数和配置进行调整，来提高 Java 程序的性能。JVM 是一个虚拟的计算机，它负责管理堆、栈、内存和线程等资源，而 JVM 的参数和配置就是控制这些资源的设置。通过调整这些参数和配置，可以优化程序的内存管理、并发性能、垃圾回收等方面，从而提高程序的性能。总之，JVM 调优需要对 Java 程序的性能瓶颈和 JVM 的参数调整有一定的了解，需要根据具体的情况选择合适的调优方法。同时，JVM 调优也需要对操作系统、硬件和网络等方面的知识有一定的了解，才能更好地进行调优。
谈谈jvm的调优思路
weixin_50055999的博客
05-20 1523
本文介绍了JVM调优的实践方法，包括四大监控指标（内存使用、GC频率、线程状态、类加载）和常见性能问题类型（频繁GC、停顿时间长、OOM等）。详细讲解了G1、CMS等垃圾回收器的特点及适用场景，并提供了推荐JVM参数配置。通过SpringBoot实战案例，演示了如何通过参数调整和代码优化（如使用StringBuilder替代字符串拼接）显著降低GC停顿时间（从180ms降至60ms），消除FullGC，提升接口响应速度（平均RT降低75%）。文章强调JVM调优应遵循"观测→分析→调整→验证&quo
JVM调优思路分解
日常工作记录，解决实际问题，不成体系。
03-06 1058
响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
JVM调优
xiaoyezhiei的博客
04-08 1167
JVM 调优是一个综合性的问题，涉及多个方面，包括内存管理、垃圾回收、线程管理、JIT 编译等。调优时通常需要先通过监控工具了解瓶颈所在，然后有针对性地进行调整。调优时要根据应用的具体需求来设置不同的参数，比如对低延迟要求高的应用选择适合的垃圾回收器，或者根据硬件配置调整堆内存大小。
记录性能问题排查及jvm调优思路
ddzyx的博客
05-25 699
只要业务逻辑代码写正确，处理好业务状态在多线程的并发问题，很少会有调优方面的需求。最多就是在性能监控平台发现某些接口的调用耗时偏高，然后再发现某一SQL或第三方接口执行超时之类的。如果你是负责中间件或IM通讯相关项目开发，或许就需要偏向CPU、磁盘、网络及内存方面的问题排查及调优技能。 根据这么多年性能压测积累的经验，归纳提炼了以下几点排查调优思路： CPU过高，怎么排查问题 linux内存 磁盘IO 网络IO java 应用内存泄漏和频繁 GC java 线程问题排查 常用 jvm 启动参数调优 一、服务
jvm调优思路及调优案例
Huangjiazhen711的博客
11-14 429
我们说jvm调优，其实就是不断测试调整jvm的运行参数，尽可能让对象都在新生代**(Eden)**里分配和回收，尽量别让太多对象频繁进入老年代，避免频繁对老年代进行垃圾回收，同时给系统充足的内存大小，避免新生代频繁的进行垃圾回收。从而减少STW()的时间。
JVM 垃圾收集器中的记忆集与读写屏障
最新发布
不要让任何事情成为你不去学习的理由。
12-14 608
记忆集是一种辅助数据结构，本质是 **“从非收集区到收集区的引用的集合”**（如老年代→新生代、Old Region→Eden Region）。它为每个收集区（如新生代的 Eden/Survivor）维护一个索引，记录哪些非收集区的内存块中存在指向该收集区的引用。组件核心作用实现方式典型使用场景记忆集（卡表）记录跨代 / 跨 Region 引用，避免全堆扫描卡表（主流）、段表、精确表CMS、G1、ParNew 等几乎所有现代收集器写屏障触发记忆集更新、维护并发标记一致性预写屏障、后写屏障；
Embabel：JVM上的AI Agent框架深度技术分析
Jackson AI
12-12 1018
Embabel是Spring创始人Rod Johnson推出的JVM AI Agent框架,采用游戏AI领域的GOAP(目标导向行动规划)算法实现确定性智能规划,区别于LangChain依赖LLM推理的方式。框架通过Spring风格的注解模型(@Agent、@Action)定义Agent,结合强类型系统和编译时检查,提供企业级的开发体验。
如何实现jvm中自定义加载器？
qsxxlc的博客
12-11 924
java运行/*** 基础自定义类加载器（遵循双亲委派）*/// 自定义类加载的根路径// 父加载器默认是应用类加载器（Application ClassLoader）/*** 重写findClass：实现从自定义路径加载.class文件的字节码*/@Overridetry {// 1. 将类全限定名转换为文件路径（如com.example.TestClass → com/example/TestClass.class）// 2. 读取.class文件的字节码。
大规模微服务下的 JVM 调优实战指南
qq_43414012的博客
12-11 804
大规模微服务JVM调优实战指南摘要 本文针对大规模微服务环境下的JVM调优挑战，提出了一套系统化的解决方案。主要内容包括： 新挑战分析：识别了资源碎片化、性能波动同步、故障传播放大和运维复杂性四大核心挑战 优化策略： 实例数与内存模型的精细平衡 集群级GC选型与协调策略 分布式架构对JVM性能的影响分析 实践方案： 提出集群级JVM管理框架 实现智能实例调度算法 提供核心服务与边缘服务的差异化配置模板 实施效果：通过动态资源分析和最优分布计算，有效避免了资源热点问题，显著提升了集群整体性能稳定性。
JVM 运行时数据区的各个组件分别存储什么内容
weixin_37926313的博客
12-11 920
区域是否线程共享存储内容是否在 JVM 堆中GC 相关堆（Heap）是对象实例、数组、字符串常量池是是（主要 GC 区域）元空间（Metaspace）是类元数据、方法字节码、运行时常量池否（本地内存）类卸载时回收，频率低虚拟机栈否局部变量、方法调用栈帧否方法结束自动释放本地方法栈否native 方法调用信息否同上程序计数器否当前执行指令地址否无。
Java技术栈五要素：JDK/JRE/JVM/Tomcat/JAR包的关系详解
日月星辰與你我同在
12-11 968
在Java生态中，JDK、JRE、JVM、Tomcat、JAR包是开发者和运维人员绕不开的五个核心概念。JDK（Java Development Kit）是Java开发的必备工具包，包含编译器（javac）、运行环境（JRE）及基础类库，为Java程序的开发、编译和运行提供完整支持。核心组成：JRE（运行时环境）：厨房的基础后厨设备和食材仓库（如刀具、炉灶、调味品）。 开发工具：研发团队的专属工具（如javac编译器、jdb调试器、javadoc文档生成器）。 定位： 开发者需要JDK来编写代码、编译程序、
JVM 与 Docker：资源限制的真相
qq_43414012的博客
12-10 699
本文探讨了JVM在容器环境中的资源适配问题。通过对比物理机与容器的资源视图差异，分析cgroup限制对JVM堆内存、GC和JIT编译的影响。文章提供了容器化JVM的核心解决方案，包括资源检测机制、内存计算方法和CPU核心数计算逻辑。其中重点介绍了容器环境检测器如何通过检查/.dockerenv文件、cgroup信息和容器运行时等特征来判断运行环境，并详细解析了如何读取cgroup中的内存限制、CPU配额等关键参数。最后提出了容器化JVM的最佳实践方案，帮助开发者在容器环境中实现JVM性能优化。
讲下 jvm 调优思路
04-17
JVM调优是指通过对Java虚拟机（JVM）的配置和参数调整，以提高Java应用程序的性能和稳定性。下面是一些JVM调优的思路： 1. 内存管理：合理配置堆内存大小（-Xmx和-Xms参数），避免过大或过小导致的性能问题。可以通过监控工具（如VisualVM）观察堆内存的使用情况，根据实际情况进行调整。 2. 垃圾回收（GC）调优：选择合适的垃圾回收器（如Serial、Parallel、CMS、G1等），根据应用程序的特点和需求进行配置。可以通过调整GC相关参数（如-XX:NewRatio、-XX:SurvivorRatio等）来优化GC性能。 3. 线程管理：合理配置线程池大小，避免线程过多导致的资源竞争和上下文切换开销。可以通过监控工具观察线程数和线程状态，根据实际情况进行调整。 4. 类加载优化：减少类加载的时间和开销，可以通过预加载、延迟加载等方式来提高类加载的效率。可以使用工具（如jmap、jstack）来分析类加载情况，找出潜在的性能瓶颈。 5. I/O优化：合理使用缓冲区、批量读写等技术，减少I/O操作的次数，提高I/O性能。可以使用工具（如jstat）来监控I/O相关指标，找出潜在的性能问题。 6. JVM参数调优：根据应用程序的特点和需求，调整JVM参数（如堆大小、栈大小、GC相关参数等），以提高性能和稳定性。可以使用工具（如jinfo）来查看和修改JVM参数。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值