高并发之-死锁

最新推荐文章于 2024-05-29 09:15:57 发布
原创 最新推荐文章于 2024-05-29 09:15:57 发布 · 451 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

死锁代码 

package com.zy.concurent;

public class DeadLock {

    public static void main(String[] args) {
        Object obj1 = new Object();
        Object obj2 = new Object();
        Thread thread1 = new Thread(new DeadLockRunalbe(obj1, obj2, 1, 2, true));
        thread1.setName("thread1");
        thread1.start();
        Thread thread2 = new Thread(new DeadLockRunalbe(obj1, obj2, 2, 1, false));
        thread2.setName("thread2");
        thread2.start();
    }

    /**
     * 线程死锁等待演示
     */
    public static class DeadLockRunalbe implements Runnable {
        Object object1;
        Object object2;
        int a, b;
        boolean flag;

        public DeadLockRunalbe(Object obj1, Object obj2, int a, int b, boolean flag) {
            this.object1 = obj1;
            this.object2 = obj2;
            this.a = a;
            this.b = b;
            this.flag = flag;
        }

        @Override
        public void run() {
            try {
                if (flag) synchronized (object1) {
                    Thread.sleep(100);
                    synchronized (object2) {
                        System.out.println(a + b);
                    }
                }
                else synchronized (object2) {
                    Thread.sleep(100);
                    synchronized (object1) {
                        System.out.println(a + b);
                    }
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

}

通过jstack查看死锁信息：

通过jps -l查看死锁的进程ID：

jstack -l 8932查看死锁进程：

E:\project\interview\src\main\java\com\zy\concurent>jstack -l 8932
2020-03-15 16:21:50
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.192-b12 mixed mode):

"DestroyJavaVM" #14 prio=5 os_prio=0 tid=0x00000000030a3800 nid=0x1184 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"thread2" #13 prio=5 os_prio=0 tid=0x000000001e7c1000 nid=0x4390 waiting for monitor entry [0x000000002038e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.zy.concurent.DeadLock$SynAddRunalbe.run(DeadLock.java:45)
        - waiting to lock <0x000000076b0f7480> (a com.zy.concurent.DeadLock$Obj1)
        - locked <0x000000076b0f9548> (a com.zy.concurent.DeadLock$Obj2)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"thread1" #12 prio=5 os_prio=0 tid=0x000000001e7c0000 nid=0x728 waiting for monitor entry [0x000000002028f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.zy.concurent.DeadLock$SynAddRunalbe.run(DeadLock.java:39)
        - waiting to lock <0x000000076b0f9548> (a com.zy.concurent.DeadLock$Obj2)
        - locked <0x000000076b0f7480> (a com.zy.concurent.DeadLock$Obj1)
        at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
        - None

"Service Thread" #11 daemon prio=9 os_prio=0 tid=0x000000001e636800 nid=0x46b8 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C1 CompilerThread3" #10 daemon prio=9 os_prio=2 tid=0x000000001e640800 nid=0x4548 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001e63e000 nid=0x1a0c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x000000001e63b000 nid=0x3b44 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x000000001e633000 nid=0x2120 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001e602000 nid=0x3d88 runnable [0x000000001fb8e000]
   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 <0x000000076b24fa98> (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 <0x000000076b24fa98> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:61)

   Locked ownable synchronizers:
        - None

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000001e53c800 nid=0x40e4 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

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

   Locked ownable synchronizers:
        - None

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000000319a800 nid=0x4d4 in Object.wait() [0x000000001f88f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076af88ed0> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x000000076af88ed0> (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=2 tid=0x000000001e523000 nid=0x2754 in Object.wait() [0x000000001f78f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076af86bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x000000076af86bf8> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

   Locked ownable synchronizers:
        - None

"VM Thread" os_prio=2 tid=0x000000001e502800 nid=0x2014 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00000000030b8800 nid=0x4524 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00000000030ba000 nid=0x4568 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00000000030bc000 nid=0x17c4 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00000000030be800 nid=0x273c runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x00000000030c0800 nid=0x3be0 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x00000000030c1800 nid=0x338c runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x00000000030c5000 nid=0x514 runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x00000000030c6000 nid=0x3f44 runnable

"GC task thread#8 (ParallelGC)" os_prio=0 tid=0x00000000030c7000 nid=0x24b4 runnable

"GC task thread#9 (ParallelGC)" os_prio=0 tid=0x00000000030c8800 nid=0x472c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001e660800 nid=0x44f8 waiting on condition

JNI global references: 12


Found one Java-level deadlock:
=============================
"thread2":
  waiting to lock monitor 0x000000001ce43728 (object 0x000000076b0f7480, a com.zy.concurent.DeadLock$Obj1),
  which is held by "thread1"
"thread1":
  waiting to lock monitor 0x000000001ce42288 (object 0x000000076b0f9548, a com.zy.concurent.DeadLock$Obj2),
  which is held by "thread2"

Java stack information for the threads listed above:
===================================================
"thread2":
        at com.zy.concurent.DeadLock$SynAddRunalbe.run(DeadLock.java:45)
        - waiting to lock <0x000000076b0f7480> (a com.zy.concurent.DeadLock$Obj1)
        - locked <0x000000076b0f9548> (a com.zy.concurent.DeadLock$Obj2)
        at java.lang.Thread.run(Thread.java:748)
"thread1":
        at com.zy.concurent.DeadLock$SynAddRunalbe.run(DeadLock.java:39)
        - waiting to lock <0x000000076b0f9548> (a com.zy.concurent.DeadLock$Obj2)
        - locked <0x000000076b0f7480> (a com.zy.concurent.DeadLock$Obj1)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

可以看到：

 java中几种工具的介绍：

jstack

jstack是java虚拟机自带的一种堆栈跟踪工具。

jstack用于生成java虚拟机当前时刻的线程快照。线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因。如线程间死锁、死循环、请求外部资源导致长时间等待等。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就知道没有响应的线程到底在后台做什么事情，或者等待什么资源。

常用命令：

jstack -l pid

jstack -m pid

jps:

java提供的一个显示当前所有java进程pid命令。适合在Linux/unix平台简单查看当前java进程的一些简单情况。

常用：jps -l

【PHP】高并发遇到死锁不知道怎么解决，看这篇足矣！
weixin_49163826的博客
11-23 850
一、什么是死锁 多线程以及多进程改善了系统资源的利用率并提高了系统 的处理能力。然而，并发执行也带来了新的问题—死锁。 死锁是指两个或两个以上的进程（线程）在运行过程中因争夺资源而造成的一种僵局（Deadly-Embrace) ) ，若无外力作用，这些进程（线程）都将无法向前推进。 下面我们通过一些实例来说明死锁现象。 先看生活中的一个实例，2个人一起吃饭但是只有一双筷子，2人轮流吃（同时拥有2只筷子才能吃）。 某一个时候，一个拿了左筷子，一人拿了右筷子，2个人都同时占用一个资源，等待另一个资源，这个时候甲
105-演示文稿-死锁检测和恢复.pdf
09-21
在多任务处理的现代计算机系统中，该问题尤其突出，尤其在互联网环境下，系统可能同时需要处理来自不同客户端的大量并发请求，死锁的发生概率也相对较高。因此，了解和掌握死锁检测与恢复的知识对于系统设计和运维...
高并发编程之死锁
weixin_38568503的博客
03-05 500
演示死锁：
慕课网实战·高并发探索（十五）：线程死锁
Never Give Up
05-08 1146
特别感谢：慕课网jimin老师的《Java并发编程与高并发解决方案》课程，以下知识点多数来自老师的课程内容。 jimin老师课程地址：Java并发编程与高并发解决方案 什么是死锁？ 通俗的说，死锁就是两个或者多个线程吗，相互占用对方需要的资源，而都不进行释放，导致彼此之间都相互等待对方释放资源，产生了无限制等待的现象。死锁一旦发生，如果没有外力介入，这种等待将永远存在，从而对程序产生严重...
并发编程与高并发解决方案（三）：死锁
eluanshi12的博客
03-04 277
互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放。（没法改变） 请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放。【增加一个中间层来破坏该条件】 不可剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放。【Java 显示锁支持通知(notify/notifyall)和等待
java高并发16——死锁
路人甲的路人乙的专栏
03-09 423
Thread Deadlock A deadlock is when two or more threads are blocked waiting to obtain locks that some of the other threads in the deadlock are holding. Deadlock can occur when multiple threads need th...
【吊打面试官系列】Java高并发篇 - 死锁的原因？
java1234的博客
05-29 239
【吊打面试官系列】Java高并发篇 - 死锁的原因？
深入理解高并发编程-核心技术原理
03-14
**面试篇**包含了高并发场景下的优化策略和常见问题，比如优化加锁方式可能导致的死锁，缓存穿透、击穿和雪崩的现象及其解决方案，以及Java中synchronized和Lock的区别和使用场景。 **系统架构篇**涉及高并发下的...
netty-高并发编程-视频教程张龙-90讲完整视频
04-25
2. 高并发基础：首先，理解并发编程的基本概念是必要的，如线程、进程、同步与互斥、死锁等。Netty利用异步事件驱动模型，通过EventLoop（事件循环）和ChannelHandler（通道处理器）等组件，实现了对大量并发连接的...
高并发情况下，MYSQL的锁等待问题分析和解决方案
12-14
问题描述 在进行高并发性能调优的时候发现了如下的一个问题： 1. 在一个事务中同时包括了SELECT，UPDATE语句 2. SELECT和UPDATE涉及到的数据为同一张表中的同一记录 3. 在并发为10的情况下就会触发数据库锁等待和死锁的情况 问题分析 在问题分析之前引入几个概念 事务隔离级别 参考文章《事务的ACID特性》 共享锁（S锁） SELECT 语句时对查询行加的锁类型为共享锁。 共享锁的特性为：不允许其他事务对该记录加排他锁，但是允许加共享锁。 保持时间：可重复度级别中共享锁会保持到事务结束。 排他锁（X锁） MYSQL的默认隔离级别（可重复度）中，UPDATE，INSERT和
多线程与高并发基础一（超发--悲观锁，乐观锁）
mengzhengjie的专栏
12-11 854
https://blog.youkuaiyun.com/zsvole/article/details/79099498 关键词： 线程，同步，单例，高并发，高访问，死锁 一、大规模并发带来的挑战 在过去的工作中，我曾经面对过5w每秒的高并发秒杀功能，在这个过程中，整个Web系统遇到了很多的问题和挑战。如果Web系统不做针对性的优化，会轻而易举地陷入到异常状态。我们现在一起来讨论下，优化的思路和方法哈。 ...
PostgreSQL高并发单行更新发生死锁
weixin_34071713的博客
01-21 1291
之前的一篇博客《PostgreSQL分区表的性能损耗验证》中，遇到100并发单行更新发生死锁(问题1)的问题。 这么简单的一条SQL，100个并发时居然会发生死锁，太不可思议了。发生死锁的SQLupdate_smallrange.sql: \setrandom id 1 10000 updatemaintbset...
java高并发学习-死锁（一）
baiwacuan6352的博客
09-16 306
死锁发生的必要条件： 1、互斥条件 2、请求和保持条件 3、资源不剥夺条件 4、环路等待条件 多线程的最佳并发实践; 1、 使用本地变量 2、使用不可变类 3、最小化锁的作用域范围 ： S = 1/(1-a+a/n) (阿木达尔定律) 其中，a为串行计算部分所占比例，n为并行处理结点个数。这样，当a=0时，最大加速比s...
死锁，死锁的四个必要条件以及处理策略
wenlijunliujuan的专栏
03-19 10万+
一、什么是死锁 二、死锁与饥饿 三、资源的类型 3.1 可重用资源和消耗性资源 3.1.1 可重用资源（永久性资源） 3.1.2 消耗性资源（临时性资源） 3.2 可抢占资源和不可抢占资源 3.2.1 可抢占资源 3.2.2 不可抢占资源 四、死锁产生的原因 4.1 竞争不可抢占资源引起死锁 4.2 竞争可消耗资源引起死锁 4.3 进程推进顺序不当引起死锁 五、产生死锁的四个必...
多线程与高并发之线程死锁
jiangzhou556的博客
05-22 321
线程死锁 需求背景 还是两个线程模拟卖火车票的场景，不过这个时候我们加上一些别的控制，来让程序产生死锁的现象，先上代码： public class ThreadTest02 implements Runnable { private static Integer count = 100; private Object obj = new Object(); public boolean flag = true; @Override public void ru
高并发下数据库插入操作死锁问题
一瓢西湖水的博客
12-28 3160
比如说本篇博客中的A表与B表可以校验两者的数据一致性，因为高并发会时时刷新数据，因此即使是死锁造成的短暂的数据不一致，在下一次刷新时，也会刷新为最新的数据。此场景在多线程批量同时对两张表进入插入操作，一张A表，一张B表，A表是原始数据表，B表是处理数据表，插入B表时，每批次插入数据量为50，产生死锁导致数据不一致问题。在一个事务中的 INSERT 按照主键或唯一键的顺序增序插入，即 session1 可以先插入 a=33 的记录，再插入 a=35 的记录，可一定程度避免受到 GAP 锁的影响。
高并发编程：8、多线程死锁分析
oJueQiang123456的博客
07-19 236
一、概述 甲有两个儿子A和B，乙有两个儿子C和D。 甲有一把锁钥匙在A儿子身上，乙有一把锁钥匙在C儿子身上。 A认识D，需要找D帮忙拿一下东西，但是D没有钥匙，钥匙在大哥C身上，等待大哥C办完事才能拿到钥匙。 C认识B，需要找B帮忙拿一下东西，但B没有钥匙，钥匙在大哥A身上，等待大哥A办完事才能拿到钥匙。 这样就产生了大家都在等待对方大哥办完事情，但是这事情永远不能完成，这就叫死锁。 二...
Mysql报Deadlock found when trying to get lock； try restarting transaction问题解决
热门推荐
光头强的博客
09-04 11万+
Mysql报Deadlock found when trying to get lock; try restarting transaction问题解决!! 问题发生场景 今天记录一下最近项目中遇到的一个问题,前几天在部署项目后,在线上运行过程中,突然报了入下这样的错误,从报错信息中我们可以看到,是mysql在执行update操作的时候报了一个死锁的问题,今天解决了,特此记录一下. Mysql锁类型分析 MySQL有三种锁的级别：页级、表级、行级,这个地方我遇到的问题是来自于行级锁,所以重点说一下。
高并发mysql死锁
最新发布
07-21
在高并发环境下，MySQL的死锁问题常常会导致数据库性能下降甚至服务不可用。死锁的发生通常是由于多个事务在并发执行时相互等待对方持有的锁资源，从而形成循环依赖[^1]。为了有效分析和解决这类问题，需要从以下几个方面入手： ### 1. 死锁的分析方法 #### 1.1 查看死锁日志 MySQL 提供了 `SHOW ENGINE INNODB STATUS` 命令，可以用来查看最新的死锁信息。通过该命令，可以获取到死锁发生时各个事务的详细锁等待情况，包括每个事务当前持有的锁和等待的锁。这对于定位死锁的根本原因非常关键[^4]。 #### 1.2 SQL 加锁分析 在高并发场景下，某些 SQL 语句可能会对多个索引加锁，尤其是在涉及多个字段的更新操作时。例如，`UPDATE` 语句可能先对某个索引加锁，然后再对另一个索引加锁。如果多个事务以不同的顺序对这些索引加锁，就可能导致死锁。因此，分析 SQL 语句的加锁顺序是解决死锁问题的重要步骤[^5]。 ### 2. 死锁的解决方案 #### 2.1 调整事务的执行顺序 为了避免死锁，可以在设计事务时尽量保证所有事务以相同的顺序访问资源。例如，如果多个事务都需要访问 `user_id` 和 `item_id` 这两个字段，可以统一规定事务必须先访问 `user_id`，再访问 `item_id`，从而避免不同事务以不同顺序加锁导致的循环等待[^5]。 #### 2.2 减少事务的粒度 事务的执行时间越长，持有锁的时间也就越长，从而增加了与其他事务发生冲突的可能性。因此，可以通过优化事务逻辑，减少事务中涉及的操作数量，缩短事务的执行时间，降低死锁发生的概率。 #### 2.3 使用乐观锁或重试机制 在某些场景下，可以考虑使用乐观锁（Optimistic Locking）来替代悲观锁。乐观锁通常通过版本号（Version）或时间戳（Timestamp）来控制并发更新，只有在提交时才会检查是否有冲突。如果检测到冲突，可以抛出异常并由客户端决定是否重试。这种方式可以有效减少锁的竞争，降低死锁的发生概率。 #### 2.4 避免不必要的索引更新 在执行 `UPDATE` 语句时，应尽量避免对不必要的字段进行更新。例如，如果某个字段的值在大多数情况下不会发生变化，可以在应用层判断其值是否需要修改，避免无意义的更新操作，从而减少对索引的加锁次数。 ### 3. 示例：事务加锁顺序不一致导致的死锁 假设存在三个事务，分别执行以下 `UPDATE` 语句： - 事务 A: `UPDATE table SET column1 = value1 WHERE user_id = 100;` - 事务 B: `UPDATE table SET column2 = value2 WHERE item_id = 200;` - 事务 C: `UPDATE table SET column3 = value3 WHERE user_id = 100;` 在这种情况下，事务 A 和 C 可能会先对 `user_id` 索引加锁，再对 `item_id` 或其他索引加锁，而事务 B 则可能先对 `item_id` 索引加锁，再对 `user_id` 索引加锁。如果这些事务并发执行，并且加锁顺序不一致，就可能导致死锁[^5]。 ### 4. 示例代码：乐观锁的实现 以下是一个使用乐观锁的简单示例，通过版本号来控制并发更新： ```sql -- 假设有一个表 users，包含 id、name 和 version 字段 START TRANSACTION; -- 查询当前版本号 SELECT name, version FROM users WHERE id = 1; -- 更新操作前检查版本号 UPDATE users SET name = 'new_name', version = version + 1 WHERE id = 1 AND version = current_version; COMMIT; ``` 如果在更新时发现版本号不匹配（即其他事务已经修改了该记录），则说明发生了冲突，应用层可以选择重试操作。 ### 5. 预防死锁的最佳实践 - **统一加锁顺序**：确保所有事务按照相同的顺序访问资源，避免因加锁顺序不一致而导致的死锁。 - **减少事务执行时间**：尽量在事务中执行必要的操作，减少事务的执行时间和锁的持有时间。 - **合理设计索引**：确保查询语句能够高效地使用索引，减少不必要的锁竞争。 - **使用合适的隔离级别**：根据业务需求选择适当的事务隔离级别，避免过高的隔离级别导致更多的锁竞争。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值