关于双重锁

最新推荐文章于 2024-04-12 10:00:00 发布
最新推荐文章于 2024-04-12 10:00:00 发布
阅读量9.3k 收藏 4
点赞数 3
分类专栏： 基础语言

Double-Checked Locking( 双检锁 ) 是普遍应用的技术，尤其在多线程环境下是实现延迟加载的有效方法。

然而，在其 Java 实现中，如果不做同步控制它不能保证在任何平台总能正确的执行。而在其他语言实现中如： C++ ，双检锁能否正确执行取决于处理器的内存模型、编译器的对指令的乱序优化以及编译器与同步库之间的相互影响。因为上面三种因素在诸如 C++ 等编程语言中并没有明确的规范，因此，很难明确的说明在什么情形下双检锁能正确执行。在 C++ 中显式的内存障栅 (Memory Barrier 解释见 : http://en.wikipedia.org/wiki/Memory_barrier) 能保证双检锁正确执行，但在 Java 中并没有此类内存障栅。

为了解释程序执行的预期行为，看下面的代码 :

[java] view plain copy print ?
  1. // Single threaded version   
  2. class Foo {   
  3.   private Helper helper = null;  
  4.   public Helper getHelper() {  
  5.     if (helper == null)   
  6.         helper = new Helper();  
  7.     return helper;  
  8.     }  
  9.   // other functions and members...   
  10.   }  
// Single threaded version
class Foo { 
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) 
        helper = new Helper();
    return helper;
    }
  // other functions and members...
  }

 

如果这段代码运行在多线程环境，存在很多导致运行出错的情形。最显而易见的是 : 可能在 Foo 中分配不止一个 Helper 对象 ( 还有其他问题待会下面再解释 ) ，要修复这个问题只需给 getHelper 方法加上同步：

[java] view plain copy print ?
  1. // Correct multithreaded version   
  2. class Foo {   
  3.   private Helper helper = null;  
  4.   public synchronized Helper getHelper() {  
  5.     if (helper == null)   
  6.         helper = new Helper();  
  7.     return helper;  
  8.     }  
  9.   // other functions and members...   
  10.   }  
// Correct multithreaded version
class Foo { 
  private Helper helper = null;
  public synchronized Helper getHelper() {
    if (helper == null) 
        helper = new Helper();
    return helper;
    }
  // other functions and members...
  }

 

上面的代码中，每次调用 getHelper() 方法都会执行同步操作，而双检锁则是避免每次调用都进行同步的习惯用法（只有 helper 对象在第一次构造的时候需要同步）。

[java] view plain copy print ?
  1. // Broken multithreaded version   
  2. // "Double-Checked Locking" idiom   
  3. class Foo {   
  4.   private Helper helper = null;  
  5.   public Helper getHelper() {  
  6.     if (helper == null)   
  7.       synchronized(this) {  
  8.         if (helper == null)   
  9.           helper = new Helper();  
  10.       }      
  11.     return helper;  
  12.     }  
  13.   // other functions and members...   
  14.   }  
// Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo { 
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) 
      synchronized(this) {
        if (helper == null) 
          helper = new Helper();
      }    
    return helper;
    }
  // other functions and members...
  }


 

不幸的是，以上代码在当前优化编译器或共享内存式的多处理器中不能正常工作。

有很多原因导致代码执行失败，我们先描述一些比较明显的出错情形，等明白这些后你可能会尝试修复双检锁的惯用法。但是你的方法很可能不会奏效：因为其中还有很多微妙的原因。明白这些后，你想出一个更好的修复方法，但是仍旧不会奏效，因为还有更多秘密蕴含其中。

很多聪明的人花费了大量时间研究这个，看有没有办法在保证执行正确的情况下，无需每个访问 helper 对象的线程都进行同步。

 

1．  最明显的导致执行失败的情形是：当初始化 Helper 对象时，对 helper 实例赋值这一操作可能已经完成也可能没有。因此，当一个线程调用 getHelper() 可能看到一个非空的 helper 引用，但此时 Helper 对象并没有完成全部的初始化工作，线程这时看到的 helper 对象里面的值都是默认值，而不是 Helper() 构造函数里面设置的值。

如果编译器将构造函数的调用内联化，那么 Helper 对象的初始化和对 helper 实例赋值的指令可以随意重新排序，只要编译器能够确保构造器不会抛出异常或执行同步。即使编译器不重新排序指令，在多处理器系统中，当某个线程运行在一个处理器上，另外的处理器或内存系统可能打乱写操作顺序。 ( 具体细节见：more detailed description of compiler-based reorderings)

 

一个测试失败执行的案例：

Paul Jakubik 找到一个使用双检锁无法正常执行的例子。当运行的系统使用 SymantecJIT ，代码不能正常工作。特别的， SymantecJIT 编译： singletons[i].reference = new Singleton(); 时产生的机器码如下：

[java] view plain copy print ?
  1. 0206106A   mov         eax,0F97E78h  
  2. 0206106F   call        01F6B210                  ; 为Singleton分配空间，返回值到eax    
  3. 02061074   mov         dword ptr [ebp],eax       ; EBP 是 &singletons[i]的引用 ，未构造好的对象存储在这里  
  4. 02061077   mov         ecx,dword ptr [eax]       ; 取消引用句柄获取原始指针  
  5. 02061079   mov         dword ptr [ecx],100h      ; 接下来的4行是Singleton的内联构造函数   
  6. 0206107F   mov         dword ptr [ecx+4],200h      
  7. 02061086   mov         dword ptr [ecx+8],400h  
  8. 0206108D   mov         dword ptr [ecx+0Ch],0F84030h  
0206106A   mov         eax,0F97E78h
0206106F   call        01F6B210                  ; 为Singleton分配空间，返回值到eax  
02061074   mov         dword ptr [ebp],eax       ; EBP 是 &singletons[i]的引用 ，未构造好的对象存储在这里
02061077   mov         ecx,dword ptr [eax]       ; 取消引用句柄获取原始指针
02061079   mov         dword ptr [ecx],100h      ; 接下来的4行是Singleton的内联构造函数 
0206107F   mov         dword ptr [ecx+4],200h    
02061086   mov         dword ptr [ecx+8],400h
0206108D   mov         dword ptr [ecx+0Ch],0F84030h

 

正如上面演示的，对 singletons[i].reference 赋值的操作，是在构造器被调用前执行的。而这在现有的JMM 下是完全合法的，C/C++ 同样也合法( 它们都没有指定内存模型)

 

无法正常工作的修复方式：

通过上面的解释，有人提出如下的解决方法;

[java] view plain copy print ?
  1. // (Still) Broken multithreaded version   
  2. // "Double-Checked Locking" idiom   
  3. class Foo {   
  4.   private Helper helper = null;  
  5.   public Helper getHelper() {  
  6.     if (helper == null) {  
  7.       Helper h;  
  8.       synchronized(this) {  
  9.         h = helper;  
  10.         if (h == null)   
  11.             synchronized (this) {  
  12.               h = new Helper();  
  13.             } // release inner synchronization lock   
  14.         helper = h;  
  15.         }   
  16.       }      
  17.     return helper;  
  18.     }  
  19.   // other functions and members...   
  20.   }  
// (Still) Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo { 
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) {
      Helper h;
      synchronized(this) {
        h = helper;
        if (h == null) 
            synchronized (this) {
              h = new Helper();
            } // release inner synchronization lock
        helper = h;
        } 
      }    
    return helper;
    }
  // other functions and members...
  }

 

这段代码把Helper 对象的构造放进了内部同步块中，这里的想法是在同步锁释放的地方需要一个Memory Barrier 以阻止Helper 对象的初始化操作和对helper 实例赋值操作之间的乱序。

但是，这个想法是错误的，同步不是按照那个规则执行的。Monitorexit 执行的规则是在monitorexit 前面的动作，必须在monitor 释放前执行。然而，并没有规则说明monitorexit 之后的动作不会在monitorexit 释放前执行。编译器将赋值语句：helper=h ；放进里面的同步块中是合理的，这样又回到了前面我们介绍的情形。许多处理器提供了这种执行单路memory barrier 的指令，因为像上面这种以变更语义的方法，通过释放锁来获取全局的Memory Barrier 的方式是由性能上的损耗的。

 

更多无法凑效的修复方法

也许你想强制让writer 执行一个全局、双向的memory barrier ，但这种方式臃肿，低效而且一旦JMM 进行修订就不能保证能正确工作了。然而，即使线程在初始化helper 对象时使用全局的memory barrier ，仍不能达到预期的目标。在有些系统中，线程如果要看到一个非空的helper 实例，也需要执行memory barrier 。因为处理器中有对内存数据的本地 cache ，一些处理器，除非执行一条cache coherence 指令如memory barrier ，否则即使其他处理器使用memory barrier 把结果写入全局内存中，处理器执行的还是本地cache 保存的过时的数据。( 这里说明了需要使用 volatile 变量 的理由) 。

这是一个讨论在Aopha 处理器发生这种情形的页面：http://www.cs.umd.edu/~pugh/java/memoryModel/AlphaReordering.html。

 

是否值得这么麻烦去做：

对大多数应用，执行getHeler 方法进行同步的代价并不会很大。应用中当这种同步对性能造成负担时有必要考虑使用其他的方法。比如：不使用交换排序而使用Java 内置的归并排序时同步会有较大的性能影响。

 

使用静态单例：

如果你创建的是静态的单实例，那么会有更好的解决方法。只需在单独的类中定义一个静态实例，Java 的语义会保证实例只有在主动使用时被初始化，且任何线程看到的总是完整的初始化结果。

[java] view plain copy print ?
  1. class HelperSingleton {  
  2.   static Helper singleton = new Helper();  
  3.   }  
  4.     
class HelperSingleton {
  static Helper singleton = new Helper();
  }
 

32 位原始数据类型能正常工作

尽管双检锁惯用法不适用于对象引用，但是对32 位的原始数据类型是可以正常工作的。需要注意的是long 和double 类型也是不能正常工作的，因为64 位原始数据类型的读写操作，如果不同步的话也是不能保证原子性的。

[java] view plain copy print ?
  1. // Correct Double-Checked Locking for 32-bit primitives   
  2. class Foo {   
  3.   private int cachedHashCode = 0;  
  4.   public int hashCode() {  
  5.     int h = cachedHashCode;  
  6.     if (h == 0)   
  7.     synchronized(this) {  
  8.       if (cachedHashCode != 0) return cachedHashCode;  
  9.       h = computeHashCode();  
  10.       cachedHashCode = h;  
  11.       }  
  12.     return h;  
  13.     }  
  14.   // other functions and members...   
  15.   }  
// Correct Double-Checked Locking for 32-bit primitives
class Foo { 
  private int cachedHashCode = 0;
  public int hashCode() {
    int h = cachedHashCode;
    if (h == 0) 
    synchronized(this) {
      if (cachedHashCode != 0) return cachedHashCode;
      h = computeHashCode();
      cachedHashCode = h;
      }
    return h;
    }
  // other functions and members...
  }

 

 跟int或float基本是相同的，他们能保证原子性。

实际上，假设computeHashCode 函数总是返回相同的结果，而且没有副作用( 即幂等的) ，此时你可以完全不用同步操作。(h 是32int 型，所以赋值是原子的，而函数调用也是幂等因此不会存在不一致的中间结果)

[java] view plain copy print ?
  1. // Lazy initialization 32-bit primitives   
  2. // Thread-safe if computeHashCode is idempotent   
  3. class Foo {   
  4.   private int cachedHashCode = 0;  
  5.   public int hashCode() {  
  6.     int h = cachedHashCode;  
  7.     if (h == 0) {  
  8.       h = computeHashCode();  
  9.       cachedHashCode = h;  
  10.       }  
  11.     return h;  
  12.     }  
  13.   // other functions and members...   
  14.   }  
// Lazy initialization 32-bit primitives
// Thread-safe if computeHashCode is idempotent
class Foo { 
  private int cachedHashCode = 0;
  public int hashCode() {
    int h = cachedHashCode;
    if (h == 0) {
      h = computeHashCode();
      cachedHashCode = h;
      }
    return h;
    }
  // other functions and members...
  }

 

使用显式的memory barriers保证正确执行
如果提供了显式的memory barriers指令，就能够保证双检锁模式正确执行。例如：如果使用C++，你可以使用Doug Schmidt书中的代码：

 
 
 

  
  

   
   

    
    [java] 
    
    view plain
    
    copy
    
    print
    
    ?
   
   

  
  

  
  
  1. // C++ implementation with explicit memory barriers   
  2. // Should work on any platform, including DEC Alphas   
  3. // From "Patterns for Concurrent and Distributed Objects",   
  4. // by Doug Schmidt   
  5. template <class TYPE, class LOCK> TYPE *  
  6. Singleton<TYPE, LOCK>::instance (void) {  
  7.     // First check   
  8.     TYPE* tmp = instance_;  
  9.     // Insert the CPU-specific memory barrier instruction   
  10.     // to synchronize the cache lines on multi-processor.   
  11.     asm ("memoryBarrier");  
  12.     if (tmp == 0) {  
  13.         // Ensure serialization (guard   
  14.         // constructor acquires lock_).   
  15.         Guard<LOCK> guard (lock_);  
  16.         // Double check.   
  17.         tmp = instance_;  
  18.         if (tmp == 0) {  
  19.                 tmp = new TYPE;  
  20.                 // Insert the CPU-specific memory barrier instruction   
  21.                 // to synchronize the cache lines on multi-processor.   
  22.                 asm ("memoryBarrier");  
  23.                 instance_ = tmp;  
  24.         }  
  25.     return tmp;  
  26.     }  

 
 
// C++ implementation with explicit memory barriers
// Should work on any platform, including DEC Alphas
// From "Patterns for Concurrent and Distributed Objects",
// by Doug Schmidt
template <class TYPE, class LOCK> TYPE *
Singleton<TYPE, LOCK>::instance (void) {
    // First check
    TYPE* tmp = instance_;
    // Insert the CPU-specific memory barrier instruction
    // to synchronize the cache lines on multi-processor.
    asm ("memoryBarrier");
    if (tmp == 0) {
        // Ensure serialization (guard
        // constructor acquires lock_).
        Guard<LOCK> guard (lock_);
        // Double check.
        tmp = instance_;
        if (tmp == 0) {
                tmp = new TYPE;
                // Insert the CPU-specific memory barrier instruction
                // to synchronize the cache lines on multi-processor.
                asm ("memoryBarrier");
                instance_ = tmp;
        }
    return tmp;
    }


使用TheadLocal修复双检锁
Alexander Terekhov (TEREKHOV@de.ibm.com) 提出一个巧妙的方法即通过线程局部存储实现双检锁。每一个线程都保持有一个局部标志来判断显示是否完成所需的同步操作。
 
 
 

  
  

   
   

    
    [java] 
    
    view plain
    
    copy
    
    print
    
    ?
   
   

  
  

  
  
  1. class Foo {  
  2.   /** If perThreadInstance.get() returns a non-null value, this thread 
  3.   has done synchronization needed to see initialization 
  4.   of helper */  
  5.          private final ThreadLocal perThreadInstance = new ThreadLocal();  
  6.          private Helper helper = null;  
  7.          public Helper getHelper() {  
  8.              if (perThreadInstance.get() == null) createHelper();  
  9.              return helper;  
  10.          }  
  11.          private final void createHelper() {  
  12.              synchronized(this) {  
  13.                  if (helper == null)  
  14.                      helper = new Helper();  
  15.              }  
  16.       // Any non-null value would do as the argument here   
  17.              perThreadInstance.set(perThreadInstance);  
  18.          }  
  19.  }  

 
 
class Foo {
  /** If perThreadInstance.get() returns a non-null value, this thread
  has done synchronization needed to see initialization
  of helper */
         private final ThreadLocal perThreadInstance = new ThreadLocal();
         private Helper helper = null;
         public Helper getHelper() {
             if (perThreadInstance.get() == null) createHelper();
             return helper;
         }
         private final void createHelper() {
             synchronized(this) {
                 if (helper == null)
                     helper = new Helper();
             }
      // Any non-null value would do as the argument here
             perThreadInstance.set(perThreadInstance);
         }
 }


这种实现方法的性能开销不同的JDK实现有较大的差别。在SUN JDK1.2中，ThreadLocal执行很慢，但1.3快了很多，1.4更快了。
Doug Lea analyzed the performance of some techniques for implementing lazy initialization .

在新的JMM下：
JDK5，提出了新的JMM和线程规范 a new Java Memory Model and Thread specification .。
使用Volatile修复双检锁：
JDK5及以后的版本扩展了原有Volatile的语义以确保系统对一个Volatile变量的写操作跟前面的读写操作不会被重新排序，读操作也如此。更多的细节见： this entry in Jeremy Manson's blog 
这样，在双检锁中声明helper变量为Volatile即可，这种方式在JDK1.4及以前不能正常工作：

 
 

  
  

   
   

    
    [java] 
    
    view plain
    
    copy
    
    print
    
    ?
   
   

  
  

  
  
  1. // Works with acquire/release semantics for volatile   
  2. // Broken under current semantics for volatile   
  3.   class Foo {  
  4.         private volatile Helper helper = null;  
  5.         public Helper getHelper() {  
  6.             if (helper == null) {  
  7.                 synchronized(this) {  
  8.                     if (helper == null)  
  9.                         helper = new Helper();  
  10.                 }  
  11.             }  
  12.             return helper;  
  13.         }  
  14.     }  

 
 
// Works with acquire/release semantics for volatile
// Broken under current semantics for volatile
  class Foo {
        private volatile Helper helper = null;
        public Helper getHelper() {
            if (helper == null) {
                synchronized(this) {
                    if (helper == null)
                        helper = new Helper();
                }
            }
            return helper;
        }
    }

 
不可变对象的双检锁：
如果Helper对象是不可变的，比如：Helper对象的所有实例变量都是final，此时双检锁不需使用volatile关键词。其主要原理是对不可变对象如：String，Integer的引用的读写操作跟基本的32位数据类型一样，都能保证原子性。

Descriptions of double-check idiom

赵小刚
关注
  • 3
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
单例双重锁的原因
u014253011的博客
01-09 774
class Singleton { private static volatile Singleton instance; private Singleton(){} public static Singleton getInstance() { if ( instance == null ) { synchronized (Sin...
双重检查锁
09-22
### 双重检查锁——新旧内存模型的对比 #### 一、双重检查锁概念解析 双重检查锁(Double-Checked Locking, DCL)是一种在多线程环境中用于实现懒加载(lazy loading)的设计模式。它通过两次检查来确定是否需要获取锁...
关于双重锁的问题
sylvilagus的专栏
12-07 1127
今天看到了一篇转载的文章阐述有关双重锁这一方法实际上在很多环境中根本无效的问题。本想转载，但由于此文是转载而且并未表明原文地址，所以在这里只简单记录一下我的理解。 双重锁设计初衷是为了减少使用synchronized关键字，因为同步会带来比较大的性能开销，并非是因为可能存在多个线程同时进入synchronized标注的方法而导致重复创建对象的现象，这一点我之前的理解是完全错误的。 而所谓双重锁
双重锁定
qinghuo23的专栏
06-09 454
public sealed class Singleton { static Singleton instance=null; static readonly object padlock = new object();   Singleton() { }   public static Singleton Instance { get { if (instance==n
星辉双重震动锁机源码
04-02
在IT行业中，"星辉双重震动锁机源码"是一个涉及到设备安全和用户认证的专题。这个主题的核心是通过特定的震动模式来实现设备的锁定和解锁功能，为用户提供一种新颖且安全的交互方式。下面将详细介绍这个技术知识点：...
电子功用-双重锁合电梯厅门联锁
09-15
在这个特定的案例中，我们关注的是“双重锁合电梯厅门联锁”，这是一种增强安全性、提高可靠性的设计策略。 双重锁合机制意味着电梯厅门的闭合状态需要通过两个独立的感应器或开关来确认，这两个开关通常分布在门的...
密码锁_密码锁_
10-04
此外，还可以增加生物识别技术，如指纹或面部识别，作为双重认证，进一步提升安全性。 总的来说，密码锁的设计涉及电子工程、软件编程和安全策略等多个领域。通过单片机的控制，电子密码锁可以实现更高级的功能，...
电子政务-双重电动锁风阀.zip
09-15
在标题提到的“双重电动锁风阀”中，我们可以理解为这是电子政务系统中的一个特定组成部分，可能是用于保障数据安全或者系统稳定性的关键设备。它可能涉及到数据加密、权限控制和网络安全等多个方面。 首先，我们要...
单例的双重锁
zmh942664的博客
05-28 404
public sealed class Singleton { private static Singleton myInstance; private static readonly object lookroot = new object(); private Singleton() { } public static Singleton GetInst...
Java中双重检查锁（double checked locking）
最新发布
pleaseprintf的博客
04-12 1814
前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。点击跳转到网站，这篇文章男女通用，看懂了就去分享给你的码吧。双重检查锁（Double-Check Locking）,顾名思义,通过两次检查,并基于加锁机制,实现某个功能。// 此处如果有多个执行流同时进入，会造成多次初始化// 第1次，一般性检查，但是有并发隐患：可能有多执行流同时进入改处// 此处第2次检查，为了防止后续多执行流并发时，后续获取同步锁的执行流，不会再次初始化Singleton对象。
双重锁原理
kunzai6的博客
03-09 656
public BusDBManager getBusDBInstance(){ if (mBusDBManager == null){ synchronized (BusDBManager.class){ if (mBusDBManager == null) { mBusDBManager = new BusDBMan
单例模式-双重锁
记录个人学习笔记总结，遇见问题等
03-28 533
public class Singleton { private static volatile Singleton singleton; // volatile 相当于防止下面两个 == null 判断不被打乱 private Singleton() {} public static Singleton getInstance() { // 防止每次调用方法都上锁 if (singleton == null) { .
14、单例（双重锁和内部类）
u011603018的博客
03-15 137
###单例模式 单例模式是在一个应用中，该类只有1个实例 1、需要将构造方法私有化。 2、获取实例的方法static 3、有饿汉和懒汉模式。饿汉模式是线程安全的。会影响启动速度 懒汉模式会在用的时候，再去创建。但是是线程不安全的，双重锁和内部类可以使懒加载是线程安全的 ###双重锁 /** 懒汉模式 细粒度（线程安全的） */ public class SingletonLazySa...
volatile引出的单例模式之双重检查
weixin_41209919的博客
05-16 593
volatile 作用！！！！ 保证线程可见性（MESI,利用CPU的缓存一致性协议） 禁止指令重排序(CPU) 单例模式之双重检查 在实现单例模式时，如果未考虑多线程的情况，就容易写出下面的错误代码： public class Singleton { private static Singleton uniqueSingleton; private Singleton() { } public Singleton getInstance() { if
双重检查锁，真的靠谱吗？
fzghjx的博客
07-27 472
先说答案，不靠谱！ 一般说，单例模式加载的时候，使用了饿汉式，类一加载就初始化；使用了懒汉式，调用的时候才初始化。 懒汉式，一般又有几种线程安全的方式。其中有一种就很著名：双重锁检查。 至于由来，百度就好了~ 上代码： public class Test{ private static Singleton singleton; public static Singleton get...
java 双检查锁定原理,什么是双重检查锁定?为什么要进行双重检查锁定?JAVA如何实现双重检查锁定...
weixin_42132056的博客
03-20 560
现场新闻发言人由已确定的()发布。PGM-48钢轨打磨车的偏转电机内电磁制动器缓解所需的电源电压为()。根据企业内部资源条件和外部环境，确定企业的经营范围是()要解决的主要问题。采煤机截割部传动装置润滑十分重要，最常用的方法是()。未经验收的建筑工程不得交付使用。酯化釜停止进料后，热媒主管温度()。Q390中的Q及数字表示()。弱酸性染料染羊毛，元明粉是起促染作用1991年5月23-25日，全省第...
java 双重检验锁
01-13
双重检验锁（Double Checked Locking）是一种在多线程环境下延迟初始化对象的技术。它通过在第一次检查对象是否为空时加锁，然后再次检查对象是否为空来确保只有一个线程创建对象。以下是Java中使用双重检验锁实现...
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值