jstack的用途（简）

于 2019-07-21 16:35:11 发布
阅读量1.6k 收藏
点赞数
分类专栏： 内存监控
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/THG_TERCEL/article/details/96731505
版权

jstack作用：用于显示指定进程内线程的信息

语法：jstack [option] <pid>

    -F 当’jstack [-l] pid’没有响应的时候强制打印栈信息,（如果直接jstack无响应时，用于强制jstack），一般情况不需要使用

    -l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表，会使得JVM停顿得长久得多（可能会差很多倍，比如普通的jstack可能几毫秒和一次GC没区别，加了-l 就是近一秒的时间），-l 建议不要用。一般情况不需要使用

    -m 打印java和native c/c++框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧，一般应用排查不需要使用

     pid：进程id

    下面给出执行命令后的结果：

C:\Users\THG>jstack -F 15884
Attaching to process ID 15884, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 25.131-b11
Deadlock Detection:

No deadlocks found.

Thread 10: (state = BLOCKED)


Thread 9: (state = BLOCKED)


Thread 8: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=59, line=143 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2, line=164 (Interpreted frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 (Interpreted frame)


Thread 7: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=502 (Interpreted frame)
 - java.lang.ref.Reference.tryHandlePending(boolean) @bci=54, line=191 (Interpreted frame)
 - java.lang.ref.Reference$ReferenceHandler.run() @bci=1, line=153 (Interpreted frame)


Thread 5: (state = IN_JAVA)
 - neicunjiankong.One.main(java.lang.String[]) @bci=0, line=17 (Interpreted frame)
C:\Users\THG>jstack -l 15884
2019-07-21 16:19:46
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode, sharing):

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x02ef9400 nid=0x5164 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x02ef2400 nid=0x38f4 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

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

   Locked ownable synchronizers:
        - None

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

   Locked ownable synchronizers:
        - None

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x02ed4000 nid=0x535c in Object.wait() [0x155cf000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x05008978> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x05008978> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

   Locked ownable synchronizers:
        - None

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x02e77000 nid=0x309c in Object.wait() [0x1553f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x05006a90> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x05006a90> (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=0 tid=0x02a8c800 nid=0x5348 runnable [0x0295f000]
   java.lang.Thread.State: RUNNABLE
        at neicunjiankong.One.main(One.java:17)

   Locked ownable synchronizers:
        - None

"VM Thread" os_prio=2 tid=0x02e73400 nid=0x529c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x15ee0800 nid=0x380 waiting on condition

JNI global references: 6

    上面代码解读：“Service Thread”中的 daemon表示线程是否是守护线程；

                             “C1 Compiler Thread()”中的prio指线程的优先级

                             "Attach Listener"中

                                  os_prio指该线程对应的操作系统线程的优先级；

                                  tid：java中线程编号；

                                  nid：即native id，该线程对应的操作系统中本地线程编号，每一个java线程都有一个对应的操作系统线程。

                             "Finalizer"指线程名；下一行中的java.lang.Thread.State：指线程状态；WAITING (on object monitor)：表示该线程处于等待状态，括号中的内容说明了导致等待的原因。

C:\Users\THG>jstack -m 15884
Attaching to process ID 15884, please wait...
Debugger attached successfully.
Client compiler detected.
JVM version is 25.131-b11
Deadlock Detection:

No deadlocks found.

----------------- 0 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x010f5055      javaw + 0x5055
0x010f33aa      javaw + 0x33aa
0x010f4497      javaw + 0x4497
0x010f3638      javaw + 0x3638
0x00000003              ????????
0x08009f99              ????????
----------------- 1 -----------------
0x7797c58c      ntdll!ZwWaitForWorkViaWorkerFactory + 0xc
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 2 -----------------
0x02f620e4      * neicunjiankong.One.main(java.lang.String[]) bci:0 line:17 (Interpreted frame)
0x02f50697      <StubRoutines>
0x65eaaf45      jvm!JVM_GetThreadStateNames + 0x4d395
0x65f713ae      jvm!_JVM_FindSignal@4 + 0x6402e
0x65eaafde      jvm!JVM_GetThreadStateNames + 0x4d42e
0x65e2cb97      jvm!JNI_GetCreatedJavaVMs + 0x6f27
0x65e3512f      jvm!JNI_GetCreatedJavaVMs + 0xf4bf
0x010f22ab      javaw + 0x22ab
0x010faebf      javaw + 0xaebf
0x010faf49      javaw + 0xaf49
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 3 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0fbcd      jvm!_JVM_FindSignal@4 + 0x284d
0x65eacbdc      jvm!JVM_GetThreadStateNames + 0x4f02c
0x65eacf0c      jvm!JVM_GetThreadStateNames + 0x4f35c
0x65ed2b41      jvm!JVM_GetThreadStateNames + 0x74f91
0x65ed2f02      jvm!JVM_GetThreadStateNames + 0x75352
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 4 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0fcd9      jvm!_JVM_FindSignal@4 + 0x2959
0x65eb1c11      jvm!JVM_GetThreadStateNames + 0x54061
0x65ec7744      jvm!JVM_GetThreadStateNames + 0x69b94
0x65e52155      jvm!_JVM_MonitorWait@16 + 0x95
0x02f5d3d3      * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x02f54854      * java.lang.Object.wait() bci:2 line:502 (Interpreted frame)
0x02f54854      * java.lang.ref.Reference.tryHandlePending(boolean) bci:54 line:191 (Interpreted frame)
0x02f54300      * java.lang.ref.Reference$ReferenceHandler.run() bci:1 line:153 (Interpreted frame)
0x02f50697      <StubRoutines>
0x65eaaf45      jvm!JVM_GetThreadStateNames + 0x4d395
0x65f713ae      jvm!_JVM_FindSignal@4 + 0x6402e
0x65eaafde      jvm!JVM_GetThreadStateNames + 0x4d42e
0x65eab166      jvm!JVM_GetThreadStateNames + 0x4d5b6
0x65eab1d7      jvm!JVM_GetThreadStateNames + 0x4d627
0x65e4f36f      jvm!jio_printf + 0x9f
0x65ecdc30      jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa      jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 5 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0fcd9      jvm!_JVM_FindSignal@4 + 0x2959
0x65eb1c11      jvm!JVM_GetThreadStateNames + 0x54061
0x65ec7744      jvm!JVM_GetThreadStateNames + 0x69b94
0x65e52155      jvm!_JVM_MonitorWait@16 + 0x95
0x02f5d3d3      * java.lang.Object.wait(long) bci:0 (Interpreted frame)
0x02f54854      * java.lang.ref.ReferenceQueue.remove(long) bci:59 line:143 (Interpreted frame)
0x02f547b4      * java.lang.ref.ReferenceQueue.remove() bci:2 line:164 (Interpreted frame)
0x02f547b4      * java.lang.ref.Finalizer$FinalizerThread.run() bci:36 line:209 (Interpreted frame)
0x02f50697      <StubRoutines>
0x65eaaf45      jvm!JVM_GetThreadStateNames + 0x4d395
0x65f713ae      jvm!_JVM_FindSignal@4 + 0x6402e
0x65eaafde      jvm!JVM_GetThreadStateNames + 0x4d42e
0x65eab166      jvm!JVM_GetThreadStateNames + 0x4d5b6
0x65eab1d7      jvm!JVM_GetThreadStateNames + 0x4d627
0x65e4f36f      jvm!jio_printf + 0x9f
0x65ecdc30      jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa      jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 6 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f13519      jvm!_JVM_FindSignal@4 + 0x6199
0x65f135e7      jvm!_JVM_FindSignal@4 + 0x6267
0x65ecdc30      jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa      jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 7 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0c5d2      jvm!JVM_GetThreadStateNames + 0xaea22
0x65ecdc30      jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa      jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 8 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0fbcd      jvm!_JVM_FindSignal@4 + 0x284d
0x65eacbdc      jvm!JVM_GetThreadStateNames + 0x4f02c
0x65eacf5a      jvm!JVM_GetThreadStateNames + 0x4f3aa
0x65dc0b5b      jvm!_JVM_GetManagementExt@4 + 0x5565b
0x65ecdc30      jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa      jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 9 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0fcd9      jvm!_JVM_FindSignal@4 + 0x2959
0x65eacbd1      jvm!JVM_GetThreadStateNames + 0x4f021
0x65eacf0c      jvm!JVM_GetThreadStateNames + 0x4f35c
0x65ebb9b1      jvm!JVM_GetThreadStateNames + 0x5de01
0x65ecdc30      jvm!JVM_GetThreadStateNames + 0x70080
0x65ece4aa      jvm!JVM_GetThreadStateNames + 0x708fa
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 10 -----------------
0x7797a8fc      ntdll!ZwWaitForSingleObject + 0xc
0x74da46b2      KERNELBASE!WaitForSingleObject + 0x12
0x65f0fbcd      jvm!_JVM_FindSignal@4 + 0x284d
0x65eacbdc      jvm!JVM_GetThreadStateNames + 0x4f02c
0x65eacf0c      jvm!JVM_GetThreadStateNames + 0x4f35c
0x65ec8c94      jvm!JVM_GetThreadStateNames + 0x6b0e4
0x65ec8d37      jvm!JVM_GetThreadStateNames + 0x6b187
0x65f12ec6      jvm!_JVM_FindSignal@4 + 0x5b46
0x6d4bc556      msvcr100!_endthreadex + 0x3a
0x6d4bc600      msvcr100!_endthreadex + 0xe4
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58
----------------- 11 -----------------
0x7797c58c      ntdll!ZwWaitForWorkViaWorkerFactory + 0xc
0x767c8494      KERNEL32!BaseThreadInitThunk + 0x24
0x779741c8      ntdll!RtlAreBitsSet + 0x88
0x77974198      ntdll!RtlAreBitsSet + 0x58

    执行jstack pid命令：查看pid进程内线程信息：结果就是以上三个命令的结果加在一块。

线程与Monitor：

                                     

    进入区(Entrt Set)：表示线程通过synchronized要求获取对象的锁。如果对象未被锁住,则迚入拥有者;否则则在进入区等待。一旦对象锁被其他线程释放,立即参与竞争。

拥有者(The Owner)：表示某一线程成功竞争到对象锁。

等待区(Wait Set) ：表示线程通过对象的wait方法,释放对象的锁,并在等待区等待被唤醒。

       说明：

              一个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程为“Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是 “in Object.wait()”。 被 synchronized保护起来的代码段称为临界区，当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。

 

线程状态：

1、NEW：线程刚刚被创建，也就是已经new过了，但是还没有调用start()方法，jstack命令不会列出处于此状态的线程信息。

2、RUNNABLE：RUNNABLE这个名字很具有欺骗性，很容易让人误以为处于这个状态的线程正在运行；事实上，这个状态只是表示，线程是可运行的。一个单核CPU在同一时刻，只能运行一个线程。

3、BLOCKED：线程处于阻塞状态，正在等待一个监视器锁(monitor lock)。通常情况下，是因为本线程与其他线程公用了一个锁。其他在线程正在使用这个锁进入某个synchronized同步方法块或者方法，而本线程进入这个同步代码块也需要这个锁，最终导致本线程处于阻塞状态，

4、WAITING：等待状态，等待某个condition或monitor发生，调用以下方法可能会导致一个线程处于等待状态：（以下方法，可用线程调用，再用jstack -l <pid>查看相关信息）

       wait() 不指定超时时间，

       join() 不指定超时时间，

       park() 

5、TIMED_WAITING：线程等待指定的时间，对于以下方法的调用，可能会导致线程处于这个状态：（以下方法，可用线程调用，再用jstack -l <pid>查看相关信息）

       wait(long timeout) 指定超时时间，

       join(long millis) 指定超时时间，

       sleep(long millis) 指定超时时间，

       parkNanos(long nanos) 

       parkUntil(long deadline) 

6、TERMINATED：线程终止。

一个例子：

执行java代码：

public static void main(String[] args) {
		Object lock = new Object();
		synchronized (lock) {
			try {
				lock.wait();
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}



执行jstack命令
C:\Users\THG>jstack 14456
2019-07-21 18:11:46
Full thread dump Java HotSpot(TM) Client VM (25.131-b11 mixed mode, sharing):

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00cf7800 nid=0x3520 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x00cf0c00 nid=0x28ac waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE

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

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x00cd4000 nid=0xfa4 in Object.wait() [0x14c7f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x04608978> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x04608978> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

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

"main" #1 prio=5 os_prio=0 tid=0x0082c800 nid=0x5650 in Object.wait() [0x0087f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
    //下面是重点
        - waiting on <0x046bc4a8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:502)
        at neicunjiankong.One.main(One.java:9)
        - locked <0x046bc4a8> (a java.lang.Object)

"VM Thread" os_prio=2 tid=0x00c73400 nid=0x407c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x14f50800 nid=0x1ad8 waiting on condition

JNI global references: 6

1、main线程先locked <0x048ba168>，再waiting on <0x048ba168>，之所以先锁再等同一个对象，是因为wait方法需要先通过synchronized获得该地址对象的monitor；

2、waiting on <0x048ba168>说明线程执行了wait方法之后，释放了monitor，进入到"Wait Set"队列，等待其它线程执行地址为0x048ba168对象的notify方法，并唤醒自己，

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值