Java项目CPU100%如何处理

已于 2024-06-12 14:18:51 修改
阅读量3.2k 收藏 56
点赞数 40
文章标签： java 开发语言
于 2024-06-12 14:15:37 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_39959019/article/details/139624672
版权

1.cpu占用很高的3大类型，9大场景:

第1大类型导致CPU100%的问题： 业务类问题
1.1 死循环

while(true)条件

导致 CPU 占用率高的最简单但最具破坏性的编程错误之一就是死循环。

当程序中的循环缺乏正确的退出条件或条件从未满足时，就会出现这种情况，

死循环无休止地运行，消耗过多的处理器时间，导致CPU100%

1.2 死锁

发生死锁后，就会存在忙等待或自旋锁等编程问题，从而导致 繁忙等待问题。

即进程在不释放 CPU 的情况下反复检查条件是否满足，会导致 CPU 占用率居高不下。

这种低效率的资源使用会妨碍 CPU 执行其他任务。

1.3 不必要的代码块

在不需要的地方使用synchronized块，会导致线程竞争和上下文切换

解决方案:尽量减少同步块的使用范围.

第2大类型导致CPU100%的问题：并发类问题
1.4 大量计算密集型的任务

比如复杂的数学计算，图像处理，视频编码

计算密集型的任务需要大量的计算能力。在没有足够系统资源的情况下运行这些应用程序，可能会导致 CPU 占用率达到 100%，因为它们试图执行高要求的任务。

解决方案:优化算法，使用更高效的库，或者利用并行计算来分摊

1.5 大量并发线程

多个线程同时运行会导致对 CPU 资源的竞争，尤其是当其中许多线程都是资源密集型进程时。

这会导致所有线程获得的 CPU 时间减少，当每个线程都试图完成自己的任务时，CPU 时间可能会被耗尽。

1.6 大量的上下文切换

创建过多的线程，导致频繁的上下文切换

解决方案:使用线程池来管理线程的数量

第3大类导致CPU100%的问题：内存类问题

1.7 内存不足

当系统内存不足时，就会将磁盘存储作为虚拟内存使用，而虚拟内存的运行速度要慢得多。

这种过度的分页和交换会导致 CPU 占用率居高不下，因为处理器需要花费更多时间来管理内存访问，而不是高效地执行进程。

1.8 频繁GC

创建大量的短生命周期的对象，频繁触发GC

解决方案: 优化代码， 减少对象的创建 ，或者调整JVM的参数来优化

1.9 内存泄漏

程序持续分配内存但不释放，会导致频繁的GC

解决方案:使用内存分析工具VisualVM进行检测和修复

2.CPU100%定位的两大神器:

想要定位到具体是哪一行的代码导致， 一般都会使用下面的两大神器

  • 通常使用的jvm自带的工具jstack，

  • 还有一种就是开源神器arthas，

3 CPU 飙升100%的解决思路与方法论

setp1:查看占用CPU最高的TOPN线程

setp2:查看TOPN线程堆栈信息

setp3:根据代码针对性解决问题

4 使用jstack 解决CPU 100%问题实操

命令jstack是java堆栈的跟踪工具，可以打印出程序中所有线程的堆栈信息，包括线程状态，调用栈信息，锁信息等。

jstack可以诊断线程死锁、内存泄漏等问题

命令格式: jstack [options] pid

常用例子: jstack -l pid，查看线程的堆栈信息

堆栈信息解读:

yupengdembp:TestYupeng yupeng$ jstack -l 43953
2024-06-08 10:14:45
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode):

"Attach Listener" #10 daemon prio=9 os_prio=31 tid=0x00007fb54485a000 nid=0x3503 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fb5430b4000 nid=0x3203 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C1 CompilerThread2" #8 daemon prio=9 os_prio=31 tid=0x00007fb54407e800 nid=0x3103 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C2 CompilerThread1" #7 daemon prio=9 os_prio=31 tid=0x00007fb54400f800 nid=0x4203 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"C2 CompilerThread0" #6 daemon prio=9 os_prio=31 tid=0x00007fb54285a000 nid=0x4403 waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"Monitor Ctrl-Break" #5 daemon prio=5 os_prio=31 tid=0x00007fb5430ab000 nid=0x4503 runnable [0x0000700002427000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0x000000079570b9e0> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0x000000079570b9e0> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:47)

Locked ownable synchronizers:
- None

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fb544026000 nid=0x4603 runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:
- None

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fb544817000 nid=0x5103 in Object.wait() [0x0000700002098000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000795588ed0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- locked <0x0000000795588ed0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

Locked ownable synchronizers:
- None

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fb54303f800 nid=0x2c03 in Object.wait() [0x0000700001f95000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x0000000795586bf8> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x0000000795586bf8> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

Locked ownable synchronizers:
- None

"main" #1 prio=5 os_prio=31 tid=0x00007fb54280e000 nid=0xe03 waiting on condition [0x0000700001983000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.jvm.JVMtest.main(JVMtest.java:6)

Locked ownable synchronizers:
- None

"VM Thread" os_prio=31 tid=0x00007fb544816800 nid=0x5303 runnable

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fb544009800 nid=0x2507 runnable

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fb54300f800 nid=0x2403 runnable

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fb543010000 nid=0x2303 runnable

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fb543010800 nid=0x2a03 runnable

"VM Periodic Task Thread" os_prio=31 tid=0x00007fb5430b4800 nid=0x3f03 waiting on condition

JNI global references: 15


 

你会发现上面的信息其实是一段一段的，摘取其中的一段为大家说明:

"main" #1 prio=5 os_prio=31 tid=0x00007fb54280e000 nid=0xe03 waiting on condition [0x0000700001983000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at com.jvm.JVMtest.main(JVMtest.java:6)

main:线程名称

#1:当前线程ID，从main开始，jvm会根据线程创建的顺序为其线程编号

prio:优先级的顺序，一般默认是5

os_prio:线程对应系统的优先级

tid:java内的线程id

nid:操作系统级别的线程id，是一个十六进制

关于线程的信息:

NEW:线程新建，还没开始运行

RUNNABLE:正在java虚拟机中运行的线程

BLOCKED :被阻塞，正在等待监视器锁的线程

WAITING :无限期等待另一个线程执行特定操作的线程

TIMED_WAITING:等待另一个线程执行操作达到指定等待时间的线程

TERMINATED:已经退出的线程

我们这里关注的最多的就是nid

4.2.使用jstack解决CPU占用很高的问题并定位具体行数

先来看一段代码:

package com.jvm;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class JVMCPU {
    private static ExecutorService service = Executors.newFixedThreadPool(5);
    private static Object lock = new Object();
    public static class yupengTask implements Runnable{

        @Override
        public void run() {
            synchronized (lock){
                long sum = 0L;
                while(true){
                    sum +=1;
                }
            }
        }
    }
    public static void main(String[] args) {

        yupengTask yupengTask = new yupengTask();
        service.execute(yupengTask);

    }
}

将这段代码上传到linux服务器，并且使用nohup java JVMCPU &运行

使用top命令可以看到cpu被打满了

知道了进程的PID，如何找到进程下是哪个线程呢?可以使用命令top -Hp 26964，如下所示

从上面的图可以看到，cpu占用最多的线程是26976这个线程id，接下来就是使用jstack命令来查看程序的所有堆栈信息，但是，这里需要有一个注意的点，26976这个是一个十进制

的，使用jstack看到的nid是十六进制，所以我们需要转换，可以使用printf "%x\n"这个命令

接下来使用jstack -l 26976打印堆栈信息

2024-06-08 12:17:36
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.281-b09 mixed mode):

"Attach Listener" #10 daemon prio=9 os_prio=0 tid=0x00007f006c001000 nid=0xc7f waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"DestroyJavaVM" #9 prio=5 os_prio=0 tid=0x00007f00a0009800 nid=0x6955 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x00007f00a00f0000 nid=0x6960 runnable [0x00007f008b0ef000]
   java.lang.Thread.State: RUNNABLE
	at JVMCPU$yupengTask.run(JVMCPU.java:14)
	- locked <0x00000000f59dfcf0> (a java.lang.Object)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
	- <0x00000000f59e0ed0> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f00a00d4800 nid=0x695e runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f00a00b9800 nid=0x695d waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f00a00b6800 nid=0x695c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f00a00b5000 nid=0x695b runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f00a0082000 nid=0x695a in Object.wait() [0x00007f008b6f5000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5988ee0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
	- locked <0x00000000f5988ee0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

   Locked ownable synchronizers:
	- None

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f00a007d800 nid=0x6959 in Object.wait() [0x00007f008b7f6000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000000f5986c00> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
	- locked <0x00000000f5986c00> (a java.lang.ref.Reference$Lock)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

   Locked ownable synchronizers:
	- None

"VM Thread" os_prio=0 tid=0x00007f00a0074000 nid=0x6958 runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f00a001e800 nid=0x6956 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f00a0020800 nid=0x6957 runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007f00a00d7800 nid=0x695f waiting on condition 

JNI global references: 5

从下面的信息中就可以看到问题其实是出现在JVMCPU.java的14行左右，这里给出的是14行，但是实际情况是14行的附近,结合代码来看一下就很容易问题

"pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x00007f00a00f0000 nid=0x6960 runnable [0x00007f008b0ef000]
   java.lang.Thread.State: RUNNABLE
	at JVMCPU$yupengTask.run(JVMCPU.java:14)
	- locked <0x00000000f59dfcf0> (a java.lang.Object)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

5.使用arthas解决CPU占用很高的问题，定位具体代码行

使用arthas解决CPU 100%问题，在方法论上要用到两个命令，

  • dashboard 命令查看TOP N线程，

  • thread 命令查看堆栈信息

先来运行arthas 

输入1显示如下

输入dashboard命令可以看到是哪个线程占用cpu最高

接下来输入thread -n 3，表示最忙的前3个线程并打印信息 

从上面的图中可以看到arthas和jstack展示的信息差不多，都定位到了JVMCPU.java的14行程序 

Java内存使用异常导致CPU100%原因(线上JVM排查之二)
无界编程
08-23 1584
写这篇博客的初衷是发现线上JVM问题以及排查，觉得有必要记录并分享出来，有感于很多市面上的教程讲述JVM的教程，甚至还有很多深入到Java字节码和JVM底层源码领域等深入知识，我不否认这些理论和源码也很重要，但是很多学生学习的云里雾里，等学完这些遇到线上问题还是不会排查，实际解决工作中的问题才可以真正做到技术的融会贯通，才可以深入去学习和理解Java字节码和JVM底层源码。
线上Java应用CPU占用率100%的故障排查与分析
CyberByte的博客
09-18 328
通过使用jstack等工具获取线程栈信息，并分析定位导致CPU占用率高的线程，可以帮助我们快速排查和修复问题。最终，通过优化代码、异步处理和调整线程池配置等手段，可以降低CPU占用率，提高应用的性能和稳定性。获取线程栈信息：使用JDK提供的工具jstack，可以获取Java进程中所有线程的栈信息。通过分析线程栈，我们可以了解每个线程正在执行的代码，从而找到可能导致CPU占用率高的线程。确认CPU占用率：首先，我们需要确认应用程序的CPU占用率是否真的达到了100%，可以通过命令行工具或监控系统获取。
Java程序占用cpu99%的问题解决
yys79的专栏
06-09 1653
nnd，那天写了半天都没保存住，现在简写了。wasce2.0.11(tomcat6.0.13)使用ibmjava50，在windows系统上会造成cpu100%,java.exe占99%的情况。换sun的就没事了。
三分钟解决 Java 进程 cpu 100% 问题
2301_78976656的博客
08-23 818
要说简单也简单，如果你的思路是对的，整个处理过程不超过 3 分钟。但如果你的思路有问题，找到问题的时间就可能会无限长。
【Java开发者必看！】CPU占用飙升至100%？一文教你快速定位问题根源！
最新发布
LA1245780的博客
10-29 411
你是否曾遇到过Java应用在服务器上运行得异常缓慢，甚至导致整个系统崩溃？CPU占用率突然飙升到100%，让你措手不及？别担心，今天我们就来聊聊如何高效地排查Java进程中的CPU高占用问题。
java应用cpu占用过高问题分析及解决方法
08-29
主要介绍了java应用cpu占用过高问题分析及解决方法，具有一定参考价值，需要的朋友可以参考下。
Java面试题之cpu占用率100%，进行定位和解决
冯安晨
09-30 6072
Java面试题之cpu占用率100%，进行定位和解决
如何解决java程序CPU负载过高问题
java123456111的博客
06-29 1744
在生产环境中，有时会遇到cpu占用过高且一直下不去的场景。这种情况可能会导致服务器宕机，进而中断对外服务，也会影响硬件寿命。
[Java] CPU 100% 原因查找解决
weixin_30906671的博客
07-17 276
CPU 100%肯定是出现死锁，这个时候观察内存还是够用的，但是CPU一直100%，以下几步解决： 1. 找到进程消耗cpu最大的 $top top - 11:37:34 up 100 days, 23:25, 1 user, load average: 0.75, 0.60, 0.53 Tasks: 32 total, 3 running, 29 sleepi...
java 100%_Java项目服务器cpu占用100%解决办法
weixin_39973416的博客
02-20 285
项目上线后运行一段时间，突然发现cpu 8个逻辑核心都占用100%，心情很紧张，然后就在网上找了一些解决方法，具体如下：1.查找哪些进程在耗cpu进入服务器，top 命令看一下，发现进程6633占用了800%[[emailprotected] ~]# top2.把进程的栈dump到文件里，以便后面的分析[[emailprotected] ~]# jstack 6633 > cpu1128...
解决线上微服务容器cpu占用100%问题（java进程占用100%问题）
lijie1051的专栏
12-28 2753
解决线上微服务容器cpu占用100%问题，java进程占用100%问题
java进程 cpu300_JAVA进程占用CPU200%-300%的问题处理过程
weixin_42113456的博客
02-27 1082
故事背景今天后台管理系统出现cpu 200%-300%，导致总CPU使用忽高忽低，系统访问速度忽快忽慢。这个问题出现过一次，准备排查一下。后台管理系统使用ssm框架，用户量小，所以排除高并发的情况。java version "1.8.0_11"处理过程1.使用top查看进程的CPU使用情况[root logs]# toptop - 14:34:51 up 513 days, 4:42, 3 u...
JAVA进程CPU负载过高导致问题分析
likeflower950的博客
08-02 1061
JAVA进程CPU负载过高问题处理
java项目导致cpu100%
zxx8868526的专栏
10-30 355
1、首先通过jvm命令jstack PID > jstack.log把日志导出 2、top -h 查找出cpu100%的线程 3、把cpu100%的线程ID转换成16进制 4、在jstack.log文件中找出对应位置定位问题代码...
Java计算cpu利用率_java得到机器cpu使用率的计算方法深入理解
weixin_42394913的博客
02-28 1482
文章目录之前写熔断功能，需要获取机器的cpu使用率从/proc文件系统获取cpu使用情况： cat /proc/stat输出解释：idle (422145968) 从系统启动开始累计到当前时刻，除硬盘IO等待时间以外其它等待时间(单位：jiffies)得到：CPU利用率 = 1- (idle2-idle1)/(cpu2-cpu1)这里的idle1、idle2是从 开机到现在 的cpu空闲时间，cp...
如果你的 Java 应用把 CPU 100% 打满，该怎么办呢？
CodeFlight
09-06 2393
文章目录如果你的 Java 应用把 CPU 100% 打满，该怎么办呢？CPU 消耗过高分析上下文切换运行队列利用率定位引起 CPU 过高的代码 如果你的 Java 应用把 CPU 100% 打满，该怎么办呢？ JVM 调优，一般都是在负载压力测试情况下，对于单个节点对外提供服务出现瓶颈时，才会启用性能调优，而 JVM 调优只是其中的一部分。在进行 JVM 调优之前，我一般都会进行 CPU 消耗的分析、内存消耗的分析、磁盘 IO 的分析、网络 IO 的分析以及程序自身问题，在这些指标都正常的情况下，才会
java 程序 cpu_java程序导致cpu利用率100%的解决方法
weixin_29208327的博客
02-16 190
1)先用top找出哪个线程占着cpu#top查看cpu 100% 的进程号,如进程号为16459#top -H -p 16459然后再看是哪个pid 比较高 找到cpu为100%的PIDPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND16539 root 25 0 1673m 525m 10m ...
Java项目服务器cpu占用100%解决办法
iteye_17003的博客
12-07 348
       项目上线后运行一段时间，突然发现cpu 8个逻辑核心都占用100%，心情很紧张，然后就在网上找了一些解决方法，具体如下：        1.查找哪些进程在耗cpu         进入服务器，top 命令看一下，发现进程6633占用了800%        [root@3server ~]# top        2.把进程的栈dump到文件里，以便后面的分析       [ro...
Java 开发，当cpu占用率100%，window和Linux分别如何定位问题
aaroncgt的博客
03-08 4774
Java开发如何解决cpu100%占用率的问题
Java程序CPU占用过高(100%)解决思路和解决方案
热门推荐
张三博客
04-20 1万+
1. 线上诊断工具Arthas 详情见之前的BLGO: Web应用线上诊断工具-Arthas 2. 采用JDK自带的jstack进行排查 2.1 使用top查看进程内存占用情况 [root@honor ~]# top 2.2 使用PS来分析进程和线程的占用情况 通过这种方式来找到线程占用高的线程id [root@honor ~]# ps H -eo pid,tid,%cpu #grep 后面进行进程id [root@honor ~]# ps H -eo pid,tid,%cpu|grep 149
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值