简单死锁和栈信息、

最新推荐文章于 2024-05-14 06:32:01 发布
最新推荐文章于 2024-05-14 06:32:01 发布
阅读量930 收藏
点赞数
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/faicm/article/details/46474459
版权

==

package znotes;

public class ThreadLockTest {
	public static void main(String[] args) {
		new Thread() {
			public void run() {
				this.setName("测试线程名");
				ThreadLockTest.bb();
			};
		}.start();;
		ThreadLockTest.aa();
	}
	private static Object mon1 = new Object();
	private static Object mon2 = new Object();

	public static void aa() {
		synchronized (mon1) {
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
			}
			synchronized (mon2) {
				cc();
			}
		}
	}

	private static void bb() {
		synchronized (mon2) {
			try {
				Thread.sleep(1000);
			} catch (InterruptedException e) {
			}
			synchronized (mon1) {
				cc();
			}
		}
	}

	private static void cc() {
		System.out.println("没锁住啊");
	}

}


==

visualVm信息


2015-06-12 18:15:45
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode):

"RMI TCP Connection(3)-169.254.106.185" daemon prio=6 tid=0x000000000d5cb800 nid=0x2c74 runnable [0x000000000e45f000]
   java.lang.Thread.State: RUNNABLE
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:152)
	at java.net.SocketInputStream.read(SocketInputStream.java:122)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
	- locked <0x00000007d6cd5380> (a java.io.BufferedInputStream)
	at java.io.FilterInputStream.read(FilterInputStream.java:83)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:538)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

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

"RMI TCP Connection(2)-169.254.106.185" daemon prio=6 tid=0x000000000d5ca800 nid=0x3008 in Object.wait() [0x000000000e31d000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007d6b2ab88> (a com.sun.jmx.remote.internal.ArrayNotificationBuffer)
	at com.sun.jmx.remote.internal.ArrayNotificationBuffer.fetchNotifications(ArrayNotificationBuffer.java:449)
	- locked <0x00000007d6b2ab88> (a com.sun.jmx.remote.internal.ArrayNotificationBuffer)
	at com.sun.jmx.remote.internal.ArrayNotificationBuffer$ShareBuffer.fetchNotifications(ArrayNotificationBuffer.java:227)
	at com.sun.jmx.remote.internal.ServerNotifForwarder.fetchNotifs(ServerNotifForwarder.java:275)
	at javax.management.remote.rmi.RMIConnectionImpl$3.run(RMIConnectionImpl.java:1289)
	at javax.management.remote.rmi.RMIConnectionImpl$3.run(RMIConnectionImpl.java:1287)
	at javax.management.remote.rmi.RMIConnectionImpl.fetchNotifications(RMIConnectionImpl.java:1293)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
	at sun.rmi.transport.Transport$1.run(Transport.java:177)
	at sun.rmi.transport.Transport$1.run(Transport.java:174)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

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

"JMX server connection timeout 14" daemon prio=6 tid=0x000000000d5e2800 nid=0x2220 in Object.wait() [0x000000000d4df000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007d68b8f88> (a [I)
	at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
	- locked <0x00000007d68b8f88> (a [I)
	at java.lang.Thread.run(Thread.java:744)

   Locked ownable synchronizers:
	- None

"RMI Scheduler(0)" daemon prio=6 tid=0x000000000d5a2000 nid=0x331c waiting on condition [0x000000000e17f000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007d667a9d8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

   Locked ownable synchronizers:
	- None

"RMI TCP Connection(1)-169.254.106.185" daemon prio=6 tid=0x000000000d5a1800 nid=0x3154 runnable [0x000000000dffe000]
   java.lang.Thread.State: RUNNABLE
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:152)
	at java.net.SocketInputStream.read(SocketInputStream.java:122)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
	- locked <0x00000007d685ba90> (a java.io.BufferedInputStream)
	at java.io.FilterInputStream.read(FilterInputStream.java:83)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:538)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:744)

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

"RMI TCP Accept-0" daemon prio=6 tid=0x000000000d692000 nid=0x3294 runnable [0x000000000de9e000]
   java.lang.Thread.State: RUNNABLE
	at java.net.DualStackPlainSocketImpl.accept0(Native Method)
	at java.net.DualStackPlainSocketImpl.socketAccept(DualStackPlainSocketImpl.java:131)
	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:198)
	- locked <0x00000007d668af20> (a java.net.SocksSocketImpl)
	at java.net.ServerSocket.implAccept(ServerSocket.java:530)
	at java.net.ServerSocket.accept(ServerSocket.java:498)
	at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)
	at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:388)
	at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:360)
	at java.lang.Thread.run(Thread.java:744)

   Locked ownable synchronizers:
	- None

"测试线程名" prio=6 tid=0x000000000c13d800 nid=0x2004 waiting for monitor entry [0x000000000cf0f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at znotes.ThreadLockTest.bb(ThreadLockTest.java:35)
	- waiting to lock <0x00000007d60c10b0> (a java.lang.Object)
	- locked <0x00000007d60c10c0> (a java.lang.Object)
	at znotes.ThreadLockTest.access$0(ThreadLockTest.java:28)
	at znotes.ThreadLockTest$1.run(ThreadLockTest.java:8)

   Locked ownable synchronizers:
	- None

"Service Thread" daemon prio=6 tid=0x000000000c098800 nid=0x2cb8 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"C2 CompilerThread1" daemon prio=10 tid=0x000000000c097000 nid=0x29ec waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"C2 CompilerThread0" daemon prio=10 tid=0x000000000c092800 nid=0x33f0 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Attach Listener" daemon prio=10 tid=0x000000000adbf800 nid=0xe8 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Signal Dispatcher" daemon prio=10 tid=0x000000000adbe800 nid=0x2c7c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
	- None

"Finalizer" daemon prio=8 tid=0x000000000ad47000 nid=0x1cdc in Object.wait() [0x000000000c08e000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007d6005568> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0x00000007d6005568> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)

   Locked ownable synchronizers:
	- None

"Reference Handler" daemon prio=10 tid=0x000000000ad3e000 nid=0x2d08 in Object.wait() [0x000000000bc8f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007d60050f0> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:503)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
	- locked <0x00000007d60050f0> (a java.lang.ref.Reference$Lock)

   Locked ownable synchronizers:
	- None

"main" prio=6 tid=0x0000000002408000 nid=0x2610 waiting for monitor entry [0x00000000028cf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at znotes.ThreadLockTest.aa(ThreadLockTest.java:23)
	- waiting to lock <0x00000007d60c10c0> (a java.lang.Object)
	- locked <0x00000007d60c10b0> (a java.lang.Object)
	at znotes.ThreadLockTest.main(ThreadLockTest.java:11)

   Locked ownable synchronizers:
	- None

"VM Thread" prio=10 tid=0x000000000ad3c000 nid=0x2930 runnable 

"GC task thread#0 (ParallelGC)" prio=6 tid=0x000000000241f800 nid=0x30e0 runnable 

"GC task thread#1 (ParallelGC)" prio=6 tid=0x0000000002421800 nid=0x3318 runnable 

"GC task thread#2 (ParallelGC)" prio=6 tid=0x0000000002423000 nid=0x3224 runnable 

"GC task thread#3 (ParallelGC)" prio=6 tid=0x0000000002425000 nid=0x3074 runnable 

"VM Periodic Task Thread" prio=10 tid=0x000000000c0d2800 nid=0x3108 waiting on condition 

JNI global references: 161


Found one Java-level deadlock:
=============================
"测试线程名":
  waiting to lock monitor 0x000000000ad46d88 (object 0x00000007d60c10b0, a java.lang.Object),
  which is held by "main"
"main":
  waiting to lock monitor 0x000000000ad45788 (object 0x00000007d60c10c0, a java.lang.Object),
  which is held by "测试线程名"

Java stack information for the threads listed above:
===================================================
"测试线程名":
	at znotes.ThreadLockTest.bb(ThreadLockTest.java:35)
	- waiting to lock <0x00000007d60c10b0> (a java.lang.Object)
	- locked <0x00000007d60c10c0> (a java.lang.Object)
	at znotes.ThreadLockTest.access$0(ThreadLockTest.java:28)
	at znotes.ThreadLockTest$1.run(ThreadLockTest.java:8)
"main":
	at znotes.ThreadLockTest.aa(ThreadLockTest.java:23)
	- waiting to lock <0x00000007d60c10c0> (a java.lang.Object)
	- locked <0x00000007d60c10b0> (a java.lang.Object)
	at znotes.ThreadLockTest.main(ThreadLockTest.java:11)

Found 1 deadlock.



==

==

王飞2023
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
java 监控 native 内存_JVM内存使用情况监控
weixin_28706397的博客
02-24 1096
详解JVM 运行时内存使用情况监控java 语言, 开发者不能直接控制程序运行内存, 对象的创建都是由类加载器一步步解析, 执行与生成与内存区域中的; 并且jvm有自己的垃圾回收器对内存区域管理, 回收; 但是我们已经可以通过一些工具来在程序运行时查看对应的jvm内存使用情况, 帮助更好的分析与优化我们的代码;注: 查看系统里java进程信息// 查看当前机器上所有运行的java进程名称与pid(...
java线程死锁代码示例
08-28
jstack 可以显示当前线程的调用栈和锁的状态，从而帮助我们检测死锁。 java 线程死锁是一个非常重要的知识点，它关系到程序的正确性和可靠性。只有通过深入了解死锁的概念、原因和避免方法，我们才能编写出更加可靠...
线程死锁DEMO
kevin_Luan的专栏
03-29 6754
先来看下以下代码： public static void main(String[] args) throws IOException, InterruptedException { for (int i = 0; i < 100; i++) { new Thread(new SyncLockRunnable(1, 2)).start(); new Thread(new SyncLock
最新java程序死锁，3种方式快速找到死锁代码，从入门到深入
最新发布
2401_84003009的博客
05-14 911
由于篇幅有限，这里就不一一罗列了，20道常见面试题（含答案）+21条MySQL性能调优经验小编已整理成Word文档或PDF文档还有更多面试复习笔记分享如下本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录需要这份系统化的资料的朋友，可以点击这里获取通过jdk工具jps、jstack排查死锁问题jps、jstack都是jdk提供的命令工具，方便用户排查程序的一些问题。更详细的用法见文档最后。
Java面试题之写一个死锁代码片段的正确姿势
微信公众号：一颗向上的草莓
08-31 393
1、引言 面试的时候可能会让你写一段死锁的代码，其实如果对死锁理解深刻，写出来并不难。 其中一个典型场景，就是一个线程持有A锁，然后请求获取B锁。另外一个线程正好相反，持有B锁，等待获取A锁。 2、死锁必备的四个条件 互斥条件：资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。 不...
一文读懂Java线程堆栈
love_eat_peach的博客
11-29 758
详细介绍了什么是Java线程堆栈；如何获取Java线程堆栈信息；如何解读堆栈信息；如何借助堆栈信息分析常见问题
java程序死锁，3种方式快速找到死锁代码
sgegv的博客
05-03 885
各位读者，由于本篇幅度过长，为了避免影响阅读体验，下面我就大概概括了整理了《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》点击传送门，即可获取！各位读者，由于本篇幅度过长，为了避免影响阅读体验，下面我就大概概括了整理了[外链图片转存中…(img-csT6U3RE-1714690953617)][外链图片转存中…(img-L5i8QkjP-1714690953617)][外链图片转存中…(img-K75yypcq-1714690953617)]
linux kernel module打印指定进程栈信息
01-19
本主题聚焦于如何编写一个内核模块来打印指定进程的栈信息，这对于调试和理解系统行为非常有用。我们将深入探讨Linux内核、进程管理以及如何在内核模块中实现这一功能。 首先，了解Linux内核模块的基本结构至关重要...
死锁详解，如何表面死锁
01-01
优点是结构简单，易于管理，但中心节点故障会导致全网瘫痪，适用于局域网和广域网。 2. **总线形网络**：所有设备共享一条通信线路，同一时刻只能两台设备通信。优点是成本低，但信道冲突可能影响效率，适用于对实时...
栈信息分析工具Thead and Monitor Dump Analyzer(TMDA)
03-21
《栈信息分析工具Thead and Monitor ...通过对栈信息的深入挖掘，开发者能够更好地理解和解决Java应用程序中出现的各种问题，从而提升整体性能。在日常开发和维护工作中，善用TMDA无疑会成为优化JVM应用的一大利器。
武汉理工操作系统复习资源和实验报告
02-03
实验报告可能会包括多线程编程，线程间通信（如管程、信号量）以及死锁的概念和预防策略。 2. **内存管理**：这部分内容会涉及虚拟内存、页表、段表、内存分配和回收策略（如最佳适配、最差适配等），以及内存碎片...
[Java故障排除指南- JDK11-学习笔记]-5-线程堆栈与死锁问题检测
宋小生-中间件
05-10 649
5-线程堆栈与死锁问题检测 线程堆栈分析 在程序运行时我们想要查看程序的执行状态,可以通过进程的线程堆栈信息来分析进程的健康状态,如果获取到一个运行中的Java进程的线程堆栈呢,我们可以用这几个命令: 先查询Java进程id jps -l 通过Java进程id查询当前进程的堆栈信息 jstack -l 17389 如下是实际操作中的一个案例 ➜ ~ jps -l 288 org.jetbrains.jps.cmdline.Launcher 66245 1670 sun.tools.jps.Jps
JAVA并发| 记录一次死锁（二）与Locked ownable synchronizers
小布1994的博客
08-29 5689
package com.xiaobu.deadlock; import java.util.concurrent.*; /** * @author xiaobu * @version JDK1.8.0_171 * @date on 2019/8/21 17:16 * @description */ public class ExcuteLock { static Exec...
Locked ownable synchronizers（转）
Mr_moving
11-03 8600
public class DeadLock { public static void main(final String[] args) throws Exception { final Object lock1 = new Object(); final Object lock2 = new Object(); Thread.currentThread().setName("main-thread"); final Thread r
什么是死锁，产生死锁的原因及必要条件
热门推荐
Lce的专栏
08-11 2万+
所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。因此我们举个例子来描述，如果此时有一个线程A，按照先锁a再获得锁b的的顺序获得锁，而在此同时又有另外一个线程B，按照先锁b再锁a的顺序获得锁。如下图所示：产生死锁的原因？a. 竞争资源系统中的资源可以分为两类：可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源；......
JVM 运行时内存使用情况监控
江无羡
01-10 2万+
java 语言, 开发者不能直接控制程序运行内存, 对象的创建都是由类加载器一步步解析, 执行与生成与内存区域中的; 并且jvm有自己的垃圾回收器对内存区域管理, 回收; 但是我们已经可以通过一些工具来在程序运行时查看对应的jvm内存使用情况, 帮助更好的分析与优化我们的代码;
Java线程死锁以及问题定位
weixin_38296425的博客
08-08 2993
死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去，如果系统资源充足，进程的资源请求都能够碍到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。 产生死锁主要原因: 系统资源不足 进程运行推进的顺序不合适 资源分配不当 发生死锁的四个条件： 互斥条件，线程使用的资源至少有一个不能共享的。 至少有一个线程必须持有一个资源且正在等待获取一个当前被别的线程持有的资源。 资源不能被抢占。 循环等待。 如何解决死锁问.
死锁分析及避免死锁
程序员小金的博客
09-17 413
什么是死锁 死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 产生死锁 下面我们看一个简单的demo public class DeadLockDemo { public static void main(String[] args) { for (int i = 1; i <= 100000; i++) {
死锁后，导出线程函数调用栈
weixin_34384557的博客
02-04 166
很多时候，内核oops还是很好处理的，因为可以看到当时的函数调用栈。objdump -DS vmlinux，配合epc(程序指针)可以定位情况发生时的代码位置。有些调试器，支持断点地址设置，可以直接显示问题发生时的代码位置。 然而，当系统陷入某种死锁状态。又比如应用程序进行的系统调用不能退出等等。这种情况下，显示当前所有线程的当前函数调用栈就有很大的帮助作用了。 我们可以...
第8章 开发多进程.ppt
06-08
多线程开发需要注意线程安全、死锁和资源竞争等问题，可以通过锁、信号量、条件变量等机制解决线程间的共享资源访问问题。 总之，本章介绍了Linux多进程和多线程开发的相关知识，包括进程的概念、线程的概念、多...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值