Java中的锁（二）

已于 2024-02-23 21:51:19 修改
阅读量136 收藏
点赞数
分类专栏： Java 文章标签： 多线程 java 并发编程 锁
于 2020-10-21 22:03:50 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dghkgjlh/article/details/109211022
版权

文章目录

Java中的锁（二）实现自定义锁

锁的语义

  1. 当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中
  2. 当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器保护的 临界区代码必须从主内存中读取共享变量。

线程A释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A 对共享变量所做修改的）消息。 ·线程B获取一个锁，实质上是线程B接收了之前某个线程发出的（在释放这个锁之前对共 享变量所做修改的）消息。 ·线程A释放锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发 送消息。

自定义同步组件

思路

自定义同步组件 = 自定义同步器 + 实现Lock接口

核心操作获取锁、释放锁是通过AbstractQueuedSynchronizer-AQS-队列同步器来实现的。只需要继承AQS并根据实际场景重写某些方法，即可实现自定义同步器。如AQS的注释描述

在这里插入图片描述

然后再通过实现Lock接口，在实现的接口里，调用AQS的某些方法。即达到自定义同步组件的实现

AQS的结构是一个FIFO的双向队列。为什么是双向队列？

在这里插入图片描述

当独占锁被多个线程竞争时，未抢到锁的线程就会在上图的队列里等待，自旋。当某个线程释放锁的时候，其他线程会开始竞争锁。

  1. 假设只是一个单向队列，即head->next->tail，那么这时怎么判断获取到锁的线程的前驱是不是头结点？因为原则是Fisrt In First Out,这样就判断不了，也就保证不了FIFO原则。直接把锁按顺序给下一个线程不行吗？很可惜，确定不了最终是哪个线程抢到锁。
  2. 如果改为双向队列，即head<->next/prev<->tail。那么当某个线程释放锁的时候，其他线程竞争锁之前，判断前驱是不是头结点，如果不是，那么也就不必去竞争锁了，接着自旋。如果是，才去竞争锁。而且也保证了FIFO这一原则，因为，多个线程入队列的顺序，我们肯定可以控制，即不断的在当前节点后面(后面是tail)拼接新的节点就可以了,这一步是要保证原子性的-用compareAndSetTail。这样构造出来的队列就是按照我们指定的顺序组成的。出队列的顺序使用prev来保证。

AQS支持重写的方法

  1. protected boolean tryAcquire(int arg)-独占式(同一时刻只有一个线程可以操作)获取同步状态，重写该方法需要查询当前的state值是否符合要求，然后再进行CAS设置状态
  2. protected boolean tryRelease(int arg)-独占式释放同步状态
  3. protected int tryAcquireShared(int arg) -共享式获取同步状态，当返回结果>=0，则代表获取成功
  4. protected boolean tryReleaseShared(int arg)-共享式释放同步状态
  5. protected boolean isHeldExclusively()-基本用来判断当前线程和拿到锁的线程是不是同一个

AQS通过一个int变量state来表示同步状态，在上面几个方法中，设置状态、获取状态、修改状态都需要原子操作。直接使用AQS提供的setState()、getState()、compareAndSetState()方法即可

实现Lock接口

实现lock接口的方法，在具体方法里面调用AQS提供的模板方法，这些模板方法内部会调用上面那5个重写的方法。从而实现自定义组件的获取锁、释放锁的操作

AQS提供的可使用的模板方法
  1. void acquire(int arg)会调用tryAcquire方法
  2. boolean tryAcquireNanos(int arg, long nanos)加入了超时限制
  3. void acquireShared(int arg)会调用tryAcquireShared方法
  4. boolean tryAcquireSharedNanos(int arg, long nanos)加入了超时限制
  5. boolean release(int arg)会调用tryRelease方法
  6. boolean releaseShared(int arg)会调用tryReleaseShared方法
  7. Collection getQueuedThreads()获取在等待队列上的线程集合
实现代码
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.AbstractQueuedSynchronizer;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;

/**
 * 同一时刻内只允许两个线程同时访问，超过两个将被阻塞。
 *
 * 实现自定义的锁，要实现Lock接口
 *
 * 使用者需要继承同步器并重写指定的
 * 方法，随后将同步器Sync组合在自定义同步组件TwinsLock的实现中，
 * 并调用同步器提供的模板方法，而这些
 * 模板方法将会调用使用者重写的方法。
 * @author jacksparrow414
 * @date 2020/10/19
 */
public class TwinsLock implements Lock {
    
    /**
     * 所有自定义的同步器都要继承AQS.
     *
     * 根据自定义同步器要实现的功能，选择性的重写以下5个方法
     *
     * tryAcquire-独占式，只有一个线程可以获得锁
     *
     * tryAcquireShared-共享式，多个线程可以获得锁
     *
     * 以上两个方法：返回值大于、等于0，代表锁获得成功；反之则代表获取锁失败
     *
     * tryRelease-独占式，线程释放锁
     *
     * tryReleaseShared-共享式，共享式释放同步状态
     *
     * 以上两个方法：返回true 代表锁释放成功；反之则代表锁释放失败
     *
     * isHeldExclusively 判断当前线程和同步器中的线程是否一致
     */
    private static final class Sync extends AbstractQueuedSynchronizer {
        Sync(int count) {
            if (count <= 0) {
                throw new IllegalArgumentException("count must large then zero");
            }
            // 修改、设置、获取同步状态直接使用AQS提供的方法即可
            setState(count);
        }
    
        /**
         * 获取锁.
         * @param reduceCount
         * @return
         */
        @Override
        protected int tryAcquireShared(int reduceCount) {
            for (;;) {
                int current = getState();
                int newCount = current - reduceCount;
                if (newCount < 0 || compareAndSetState(current, newCount)) {
                    return newCount;
                }
            }
        }
    
        /**
         * 释放锁.
         * @param returnCount
         * @return
         */
        @Override
        protected boolean tryReleaseShared(int returnCount) {
            for (;;) {
                int current = getState();
                int newCount = current + returnCount;
                // 使用AQS提供的方法CAS设置值，可以保证原子性
                if (compareAndSetState(current, newCount)) {
                    return true;
                }
            }
        }
    }
    
    private final Sync sync = new Sync(2);
    
    /**
     * 实现Lock的lock、unlock接口.
     *
     * 在这些接口里调用AQS的模板方法acquire、acquireShared、release、releaseShared
     *
     * tryAcquireNanos、tryAcquireSharedNanos 这两个是有超时时间的
     *
     * 这里的方法会最终调用上面重写的方法
     */
    @Override
    public void lock() {
        sync.acquireShared(1);
    }
    
    @Override
    public void unlock() {
        sync.releaseShared(1);
    }
    
    @Override
    public void lockInterruptibly() throws InterruptedException {
    
    }
    
    @Override
    public boolean tryLock() {
        return false;
    }
    
    @Override
    public boolean tryLock(final long time, final TimeUnit unit) throws InterruptedException {
        return false;
    }
    
    @Override
    public Condition newCondition() {
        return null;
    }
    
    
}

线程间的通知机制

场景

当两个线程之间需要通信，这里的通信可以理解为线程之间互相协调完成一项工作。如某个类的对象A，在某些情况会被多线程访问。当线程M修改了一个状态state，那么线程N就要进行打印操作。这种情况怎么实现？

利用线程等待/通知机制。每个Java对象都具有wait() ,wait(long timeout)notify(),notifyAll()方法-为什么？因为每个类都默认继承了Object类，这些方法都是在Object里面的

当线程N获得当前对象A的锁之后，发现此时flag不满足条件，那么应该释放这把锁，让给其他线程执行。如果不释放，则锁一直被N占有，有可能flag一直不满足条件，则其他线程都拿不到对象A的这把锁。一旦N释放对象锁之后，此时线程M获取到了锁，M开始修改flag,修改完释放。如果之后N再次抢到了这把对象锁,则发现flag已经满足条件了,则开始执行后面的逻辑.

实现方式可以是

  1. 线程N一直监控state的状态，当flag满足时，才去争夺这把锁。当flag不满足，可以简单的休眠一段时间
  2. 这里线程N应该等待线程M的通知,得到通知后,再去争夺这把锁

实现方式一

import java.util.concurrent.TimeUnit;
import lombok.SneakyThrows;
import org.junit.Test;

/**
 * 不是用等待同步/机制，仅仅靠死循环检测，条件不满足则休眠一段时间.
 * 
 * @author jacksparrow414
 * @date 2020/10/20
 */
public final class ThreadWaitTest {
    static boolean flag = true;
    static Object lock = new Object();
    
    @Test
    @SneakyThrows
    public void assertThreadWait() {
        Thread threadN = new Thread(new ThreadN(), "threadN");
        Thread threadM = new Thread(new ThreadM(), "threadM");
        threadN.start();
        threadM.start();
        // 为了测试用例能够打印完全，特意休眠10秒
        TimeUnit.SECONDS.sleep(10);
    }
    
    static class ThreadN implements Runnable {
    
        @Override
        public void run() {
            while (flag) {
                try {
                    System.out.println(Thread.currentThread().getName() + "条件不满足，开始休眠，循环获取");
                    Thread.sleep(1000);
                } catch (InterruptedException exception) {
                    exception.printStackTrace();
                }
            }
            synchronized (lock) {
                System.out.println(Thread.currentThread().getName() + "acquire lock");
            }
        }
    }
    
    static class ThreadM implements Runnable {
        @Override
        public void run() {
            while (flag) {
                synchronized (lock) {
                    try {
                        System.out.println(Thread.currentThread().getName() + "acquire lcok");
                        // 第二种休眠方法
                        TimeUnit.SECONDS.sleep(5);
                    } catch (InterruptedException exception) {
                        exception.printStackTrace();
                    }
                    flag = false;
                }
            }
            
            synchronized (lock) {
                System.out.println("acquire again");
            }
        }
    }
}

测试结果如下：

threadN条件不满足，开始休眠，循环获取
threadM acquire lcok
threadN条件不满足，开始休眠，循环获取
threadN条件不满足，开始休眠，循环获取
threadN条件不满足，开始休眠，循环获取
threadN条件不满足，开始休眠，循环获取
threadM acquire again
threadN acquire lock

可以看到，一看是线程N判断flag不满足条件，则不去竞争锁，而是休眠一段时间。休眠期过了再重复检测。而一开始线程M是满足条件的，所以线程M执行，并修改了flag状态。执行完毕释放对象锁。由于此时N还处于线程休眠期内，则锁又被M获取了一遍，M再次执行完毕，释放锁，此时已经没有线程竞争锁，线程N休眠期一过，尝试获取锁，获得成功，执行代码

存在的问题
  1. 多个线程去竞争锁，应该是同时去竞争的，由于我们上面代码N加了线程休眠，所以在M第一次释放锁之后，N还处于休眠期内，则不会去竞争锁。这就是个问题了，本来应该在释放锁之后，线程N立刻和其他线程去竞争锁的，由于代码问题，导致线程N没去竞争。这样做的严重后果是，当竞争锁的线程很多，而线程N每次都会休眠1秒，假设，每次释放锁都在N的休眠期内，那么N将要等待所有竞争这把锁的线程使用完毕，才有机会获得锁。这明显是不符合多线程编程的初衷的。初衷是什么？初衷就是我们只管提交线程任务，谁抢到谁就执行，但绝不是这种最后才执行
  2. 由于线程休眠不消耗CPU资源，而上面的问题又是休眠期引起的，那么尝试将休眠期降低，比如降低到50毫秒、1毫秒。但是如果线程执行的任务是耗时的，那么这么频繁的休眠、检测，势必会消耗大量的CPU资源。事实是，我们永远无法确定一个线程精确的休眠期应该是多少。因为每个线程执行任务的时间是不确定的

实现方式二

为了解决实现方式一中的问题，使用线程的等待/同步机制即可。首先要获得对象锁，此时发现当前线程执行条件不满足，那么当前线程应该等待，并释放锁。接下啦，领完一个已经获得锁的线程，在即将执行完毕同步体时，使用notifyAll或者notify方法，通知等待在这把锁上的所有线程或者某一个线程。接收到通知的线程去竞争锁，谁获得了锁，谁结束wait状态

import java.util.concurrent.TimeUnit;
import lombok.SneakyThrows;
import org.junit.Test;

/**
 * @author jacksparrow414
 * @date 2020/10/20
 */
public final class ThreadWaitNotifyTest {
    static boolean flag = true;
    static Object lock = new Object();
    
    @Test
    @SneakyThrows
    public void assertThreadWaitNotify() {
        Thread threadN = new Thread(new threadN(), "threadN");
        Thread threadM = new Thread(new threadM(), "threadM");
        threadN.start();
        TimeUnit.SECONDS.sleep(1);
        threadM.start();
        TimeUnit.SECONDS.sleep(10);
    }
    
    static class threadN implements Runnable {
    
        @Override
        public void run() {
            synchronized (lock) {
                while (flag) {
                    System.out.println(Thread.currentThread().getName() + " flag is true wait");
                    try {
                        lock.wait();
                    } catch (InterruptedException exception) {
                        exception.printStackTrace();
                    }
                }
    
                System.out.println(Thread.currentThread().getName() + "falg is false running");
            }
        }
    }
    
    static class threadM implements  Runnable {
    
        @Override
        public void run() {
            synchronized (lock) {
                System.out.println(Thread.currentThread().getName() + " acquire lock");
                flag = false;
                
                try {
                    TimeUnit.SECONDS.sleep(3);
                    // 唤醒所有等待的线程
                    lock.notifyAll();
                } catch (InterruptedException exception) {
                    exception.printStackTrace();
                }
            }
            // 唤醒等待线程的操作要放到同步体里，否则会报错
            //lock.notifyAll();
            synchronized (lock) {
                System.out.println(Thread.currentThread().getName() + " acquire again");
            }
        }
        
    }
}
注意事项
  1. 使用wait、notifyAll、notify等方法时，都要在同步体里执行，也就是保证在当前线程已经获得锁的前提下执行。如果此时此时线程没有获得对象的锁，就执行，则会报错
Exception in thread "threadM" java.lang.IllegalMonitorStateException
 	at java.lang.Object.notifyAll(Native Method)
 	at com.example.mybatis.demomybatis.thread.ThreadWaitNotifyTest$threadM.run(ThreadWaitNotifyTest.java:60)
	at java.lang.Thread.run(Thread.java:748)
  1. 当一个获得锁的线程执行notify、notifyAll之后，等待在这把锁上的线程不会从wait方法返回，返回的前提一定是获得了锁之后才会结束wait状态
  2. 当线程N收到通知、竞争再次获取到锁之后，依旧要检查while条件，满足才会执行条件。其实很好理解，拿到锁，肯定要重新执行这个线程，而不是从该线程上一次地方执行
    在这里插入图片描述
    示例代码位置
JackSparrow414
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【Java多线程】JUC之深入队列同步器(AQS)（三）自定义AQS组件-独占锁(上)
墩墩分墩
12-26 521
**AQS同步器的主要实现方式是`继承`，子类通过`继承AQS同步器`并 `实现它的抽象方法` 来管理`同步状态state`** - 对于使用者来讲，我们无需关心**获取资源失败，线程排队，线程阻塞/唤醒等一系列复杂的实现**，这些都在AQS中为我们处理好了。我们只需要负责好自己的那个环节就好，也就是**获取/释放共享资源state的姿势**T_T。 - 很经典的`模板方法设计模式`的应用，AQS为我们定义好`顶级逻辑的骨架`，并提取出`公用的线程入队列/出队列，阻塞/唤醒等一系列复杂逻辑的实现`，将
Java基础-锁（二）
resourcej的博客
04-09 642
悲观锁和乐观锁 根据线程是否要锁住同步资源可以将锁分为悲观锁和乐观锁。 悲观锁 悲观锁认为自己在使用数据的时候一定有线程来修改数据，所以在获取到数据的时候会先加锁，确保数据不会被别的线程修改。 实现有：关键字 synchronized 、接口 Lock的实现类。 适用于写多读少的场景。 乐观锁 乐观锁认为自己在使用数据的时候不会被别的线程修改，所有不会添加锁，只是在更新数据的时候才去判断之前有没有...
println方法可以刷新共享变量？
日有寸进
08-18 254
看如下代码： public class SynMemory { private static boolean ready; private static int number; private static class PrintThread extends Thread{ @Override public void run() { ...
java多线程同步时，为什么在while循环里面加了System.out.println(),就能及时拿到主存中的已修改值
Hj95815的博客
07-09 858
import org.slf4j.LoggerFactory; import java.util.concurrent.TimeUnit; public class Test1234 extends Thread { private org.slf4j.Logger log = LoggerFactory.getLogger(Test1234.class); private static int flag2 = 0; public static void main(Strin.
Java并发—利用AQS实现自定义锁
m0_46628950的博客
07-20 745
Java并发—利用AQS实现自定义锁
Java的AQS锁实现原理
chuixue24的博客
04-14 342
看完整个AQS的源码，是不是完全理解了AQS加锁、释放锁、以及同步队列和条件队列数据流转的逻辑了。连AQS这么复杂的源码你都搞清楚了，下篇带你一块学习ReentrantLock源码，应该就轻松多了。
Java对文件加锁（二）
12-08 1298
上一篇文章讲的是对文件的加锁，但是在实际的过程中，会产生额外的内存消耗。一个重要的原因是，因为我们是把这些地址和锁存在一个HashMap中的，如果人为不清理的话，这个HashMap里面存放的内容就会越来越多。下面我讲另外一个Map的实现，WeakHashMap。   在介绍WeakHashMap之前，我先介绍一些WeakReference。 下面是java文档对weakreference的解释
java锁详解.pdf
12-31
Java 锁是 Java 并发编程中的一种基本机制，用于确保线程安全和避免竞争条件。Java 锁可以分为两大类：synchronized 锁和 ReentrantLock 锁。 一、Synchronized 锁 1. 锁的原理：synchronized 锁是基于对象头的 ...
浅谈对java中锁的理解
08-31
浅谈java中锁的理解 Java中的锁是指用于维护数据一致性的机制，主要用于解决多线程访问共享资源时的数据不一致问题。在Java中，锁机制主要通过synchronized关键字实现。 一、synchronized机制 synchronized机制是...
深入理解java自旋锁
08-25
Java中如何实现自旋锁？下面是一个简单的例子： ```java public class SpinLock { private AtomicReference<Thread> cas = new AtomicReference(); public void lock() { Thread current = Thread.current...
java中的锁
06-27
Java中的锁机制是多线程编程中不可或缺的一部分，它提供了对共享资源的访问控制，确保了并发环境下的数据一致性。在Java中，锁主要分为两种类型：内置锁（也称为同步锁）和显式锁。内置锁是通过synchronized关键字...
Java Redis分布式锁的正确实现方式详解
08-25
Java Redis分布式锁是指使用Redis实现的分布式锁机制，旨在解决分布式系统中的并发问题。分布式锁有三种实现方式：数据库乐观锁、基于Redis的分布式锁和基于ZooKeeper的分布式锁。本篇博客将详细介绍第二种方式，...
09-Java多线程-5、AQS-基于AQS实现自定义锁
my_momo_csdn的博客
06-04 469
文章目录一、自定义锁二、代码三、测试四、输出 一、自定义锁 ASQ设计是为了简化并发工具的实现，里面实现了大量线程状态的维护，线程间的同步等待通知等细节，java并发的锁等很多基础组件都是基于AQS来实现的，因此可以通过AQS来自定义实现锁，在AQS类的注释上我们可以看到作者Doug Lea下面一段话,具 体真的推荐去看看源码中的英文注释，非常多的注释对理解和使用AQS都很有帮助，读起来吃力可以...
【Java高并发】AQS自定义同步器
starlywang的博客
04-02 554
【Java高并发】AQS原理及其优化一、AQS概述二、基于AQS实现自定义同步器 一、AQS概述 一个FIFO的双向队列：队列元素的类型为Node，Node中的thread变量用来存放进入AQS队列里面的线程，waitStatus记录当前线程等待状态 AQS中维持了一个单一的状态信息state，可以通过getState、setState、compareAndSetState函数修改其值 AQS...
java--利用AQS自定义锁
qq_43539962的博客
01-18 107
利用AQS自定义锁lockunlock AbstractQueuedSynchronizer是阻塞式的锁和相关同步器工具的框架，用state来标识状态,通过修改这个状态来标识获取锁和释放锁 getState - 获取锁的状态,setState - 来修改状态 ，compareAndSetState - 以cas的方式来修改值保证原子性，还提供了类似于synchronized的entryList阻塞队列和多个waitSet（synchronized只有一个waitSet） @Slf4j(topic = "w.
通过AQS自定义锁
shyoushine的博客
12-23 962
自定义独占锁只需要定义自公开的内部类继承AbstractQueuedSynchronizer类重写tryAcquire和tryRelease就可以了。 package multi; import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.AbstractQueuedSynchronizer; i
《Java后端知识体系》系列之自定义AQS同步器
qq_40126996的博客
06-09 195
/** * @author admin */ public class NonReentrantLock implements Lock, Serializable { protected static class Sync extends AbstractQueuedSynchronizer{ //是否锁已经被持有 @Override protected boolean isHeldExclusively(){ retu
java双锁_Java双重锁定
weixin_28858247的博客
02-27 474
我碰到一篇文章最近讨论了Java中的双重检查锁定模式及其陷阱，现在我想知道，我已经使用多年的模式的变体是否受到任何问题。我看了很多关于这个主题的文章和文章，并了解了获得一个部分构造对象的引用的潜在问题，据我所知，我不认为我的实现是受这些问题的影响。以下模式是否有任何问题？如果没有，为什么不使用它呢？我从来没有见过在我在这个问题上看到的任何讨论中推荐的。public class Test {priv...
JMX的快速入门与使用
特别享受思考问题的过程
03-15 8865
文章目录JMX应用场景JMX使用定义一个MXBean实现该MXBean将MXBean注册到JMX中去使用Jconsole监控JMX官方文档源码地址 JMX应用场景 用来监控JVM内各种对象的信息。一个经典场景就是，某一天我们忽然被前方告知，业务大面积瘫痪，这时经过排查，发现由于bug导致数据库连接使用完了没有被释放，导致后续业务没有可用的数据库连接而超时报错。 假如我们使用JMX来监控我们系统中数据库连接池的信息，当数据库连接池出现短时间内连接被大量使用，这个时候可以搭配我们的监控报警系统（如Nagios）
Java中锁的升级和降级
最新发布
05-18
Java中的锁分为四种级别：无锁、偏向锁、轻量级锁和重量级锁，锁的级别会根据竞争情况自动升级或降级。 偏向锁是指在没有竞争的情况下，将对象头中的Mark Word标记为偏向锁，同时记录线程ID。当第二个线程访问该对象时，偏向锁会升级为轻量级锁，两个线程会进行自旋，尝试获取锁。如果自旋失败，则升级为重量级锁。 轻量级锁是指在竞争不激烈的情况下，使用CAS操作将对象头中的Mark Word标记为锁定状态，同时将锁的拥有者线程ID保存在锁对象的头部。如果自旋获取锁失败，就会升级为重量级锁。 重量级锁是指在竞争激烈的情况下，使用操作系统的Mutex Lock实现，将竞争锁的线程阻塞。 锁的降级是指从重量级锁降级为偏向锁或轻量级锁。当一个线程获取到重量级锁后，如果发现在接下来的执行过程中没有竞争，就会将锁降级为偏向锁或轻量级锁，提高并发性能。 锁的升级和降级都是由JVM自动触发的，程序员无法手动干预。通过锁的升级和降级机制，JVM可以根据程序的运行情况自适应地选择最合适的锁级别，从而提高程序的并发性能。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值