2013年8月7日星期三

P2P平台频现挤兑 “拆标”引爆流动性风险

因为遭遇“黑客攻击”,网贷平台中财在线部分用户数据泄露,间接诱发投资人恐慌。回忆起一个月前的挤兑事件,中财在线总经理甘昌武仍心有余悸。
直到7月11日恢复当天,中财在线网站尚有三四百万的成交量。随着此后大量的标的集中到期,前后垫付近600万仍难缓解资金紧缺,面对突如其来的挤兑,甘昌武不得不四处筹资。
除了抵押自己的房产借款、找亲朋好友借钱外,他还借了部分高利贷。“不管再困难,我也告诉自己不能拖欠投资人的钱。”甘昌武对《第一财经日报》表示,“只要投资人不失去信心,平台很快会渡过难关。”
这一P2P行业挤兑事件并非个案。就在这几天,位于深圳福田区卓越时代广场的P2P贷款服务平台网赢天下也令不少投资人惴惴不安。上线仅4个月,该平台已经实现了7.73亿的成交量,然而,从7月下旬起,该平台便开始出现兑付展期和提现困难的情况。
事实上,近几个月以来,网赢天下与武汉的中财在线、浙江的非诚勿贷等知名P2P平台接连出现挤兑风波,源起为不少平台惯用的“拆标”方式引爆了流动性风险。
而究其实质,一些业内人士表示,P2P行业的脆弱有目共睹,一有风吹草动就会引发挤兑,不仅反映出投资人对P2P平台的不信任,更令这一长期游走在监管盲区中的行业暴露出野蛮生长后的各种弊病。
期限错配
7月30日,网赢天下发布公告称,因银行月末大额资金流放受限,原定下午可以到位的资金未能及时到位,暂时不能提现。本报记者发现,短短数日内,该平台已经多次发布公告,以“黑客攻击”、“网络维护”等理由暂停或推迟受理提现申请。
这并不是个案。如中财在线的甘昌武就已开始对“黑客攻击”诱发的挤兑风波进行反思,并重新定位P2P平台的运作模式。
据他介绍,7月6日,中财在线遭遇“黑客攻击”,部分用户数据泄露。尽管网站已经在第一时间发布公告,但由于投资人出现恐慌,平台的兑付量有所提升。而随后,大量投资集中到期,平台垫付完后出现了自有资金紧缺。
与当前不少P2P平台一样,中财在线此前采用了“拆标”的方式,包括拆期限和拆金额,即把长期借款标的拆成短期,把大额资金拆成小额,从而造成了期限和金额的错配,因此平台要承担一定的还款压力,容易引发流动性风险。
深圳某P2P平台负责人举例称,借款人通过一家P2P平台借款120万,期限为12个月。如果该平台不拆标,那么投资人就是借出120万,所有的还款压力由借款人承担。如果出现逾期,不少P2P平台还有担保公司负责代偿。
“但是,由于这样的标的期限长、金额大,一般很难在短时间内找到合适的投资人。”该负责人称,P2P平台惯用“拆标”的方式来解决问题,例如把120万的金额拆成10份甚至100份,期限则缩短为1个月,滚动放标12次。
该负责人表示,这样操作对借款人并没有任何影响,他拿走了一笔120万、为期12个月的资金。但对于P2P平台而言,“拆标”实际上就是建造了一个资金池,进行期限错配、短贷长投。
甘昌武表示,因为期限错配,P2P平台需要有大量的自有资金来应对流动性风险。因为担保公司的代偿只针对12个月后贷款出现逾期的情况,所以在期内一旦突遇集中到期或大量提现的状况,平台需要自筹资金来垫付。
“投资人希望期限短、收益高的投资标的,借款人又希望期限长、成本低的借款。‘拆标’既可以满足双方的需求,也能提升平台自身的业务量。”甘昌武表示,这也是导致包括中财在线在内,上述三家P2P平台出现挤兑的根本原因。
他认为,抛开运营和法律的风险不谈,“拆标”的技术含量很高,不仅需要P2P平台有足够的流动性去应对可能出现的挤兑风险,与此同时,还需要专业人士很精确地设计以保证资金的流转。
“经过了这次教训,以后不会再碰‘拆标’了。”甘昌武表示,接下来要逐渐回归本业,专做“中介”撮合资金,不会再介入交易、承担风险了。
饮鸩止渴
在出现流动性风险后,这些P2P平台不得不“饮鸩止渴”。
据上述深圳某P2P平台负责人表示,为了应对挤兑,网赢天下在线上、线下大量筹资,而发放“天标”则是一种常用的线上集资手段。与早期为了制造噱头不同,现在不少平台通过发放大量“天标”,以筹资应对短期的流动性困难。
网赢天下网站上的信息显示,在7月18日出现逾期和兑付问题后,7月23日、26日、28日,该平台分别三次发放了总金额为1200万的“天标”,借款期限均为20天,到期总收益为3.25%~3.55%。以此测算,该“天标”的年化利率最高约为65%。
事实上,中财在线在发生危机后也曾通过发放“天标”线上集资。根据第三方网贷监测机构海树网统计的数据,在7月17日~7月24日期间,中财在线发放了总计约740多万的“天标”,期限从12天至1个月不等。
对此,甘昌武表示,当时资金紧缺,除了自己线下通过抵押借款等方式筹集资金外,有些投资人则表示愿意与平台共渡难关,所以就通过这样的形式筹资。平台让出了所有的利润,所以这些“天标”给投资人的利息也比较高,大约每天0.12%。
“这只是暂时的过渡措施,以后收益率会慢慢降到正常水平,不可能再有这么高了。”他表示,因为中财在线的总盘子还不算大,再加上有一部分自有资金,所以暂时度过了危机。
某资深P2P网贷人士表示,网赢天下的成交量已经有7亿多,截至目前,该平台的贷款余额也有1.4亿多,如果依靠发放“天标”这样高成本地吸收资金,恐怕会加剧风险。
“每天都有大量的‘天标’到期,这样‘饮鸩止渴’的方式很难从根本上解决当前的流动性问题,反而容易增加挤兑的风险。”该人士认为,这样的操作手段本身也已经触及违规的边界。
亟待监管
5月21日,因受“离职客服”网络爆料某网络平台伪造借款人事件影响,被“映射”的浙江非诚勿贷发生投资人挤兑。目前,事情已经过去两个多月,该平台的提现问题仍没有彻底解决。目前尚有1400多万的提现申请还在排队当中。
上述某资深P2P网贷人士认为,无论是“离职客服”、“黑客入侵”还是“贷款逾期”,无论这些偶然性事件是否与平台直接相关,它们都如此轻易地触动了投资人的神经,引发挤兑。
“一方面说明大家对于P2P行业还没有信心,任何一点风吹草动都可能成为挤兑的导火索。而另一方面更关键的问题在于,当前这些P2P平台业务运作不规范、产品设计不合理,极易引发风险。”该人士称。
海树网统计的数据显示,非诚勿贷自成立至今,其 82.2%的成交额均是由借款 1个月的标构成。而网赢天下从成立至今,一个月的标占总成交量的21.82%,一个月以下的标则占到了44.74%。
而记者登录宜信、陆金所、人人贷等网站发现,这些网贷平台发布的标的贷款期限普遍为6个月、12个月,甚至36个月,借款的年利率则远低于以短期标的为主的P2P平台。
上述某资深P2P网贷人士认为,这是一个简单判定该P2P平台是否规范的指标之一。借款期限较长不仅可以降低借款的成本,挤压投机的泡沫,更有助于P2P平台的稳定和收益。而有些平台全是一个月以下标的,肯定存在“拆标”的情况。
“P2P平台热衷于‘拆标’,因为可以在短期内大幅提升交易量。而对于投资者而言,不少人利用信用卡套现投资网贷,因此只能投资一个月以下的标的。”该人士称。
但该人士表示,如果借款期限长,意味着贷款余额是缓慢、稳步增长的,并且还款期限长,这就给P2P平台提供了足够的缓冲期。此外,因为平台大都采用等额本息还款法,所以每月还的本息逐渐越少。即便贷款余额总量很大,P2P平台依然能保持平稳。
不仅如此,据上述深圳某P2P平台负责人介绍,由于平台的在线收入包括利息管理费和借款管理费收入,而借款期限越长,平台的这部分收入越高,所以从长远发展来看,期限长有利于平台的稳定和收益。
事实上,监管层已经开始对P2P平台的规范运作给予了越来越多的关注。
7月初,央行开始全面摸底P2P行业,不仅召集了全国9家P2P平台代表举行了座谈会,央行各分支机构也开始向当地的P2P平台发放“网络金融发展状况调查问卷”。
而日前本报记者了解到,根据国务院有关批示,相关部门已经组成了“互联网金融发展与监管研究小组”,并于8月1日专程到上海、杭州两地进行调研。
研究小组从上海的网络借贷行业开始,对拍拍贷、你我贷等5家企业做了集中调研,了解上海互联网金融行业的整体发展情况;继而,研究小组还对陆金所的业务模式、担保机制、风控体系、网站安全、资金管理等方面进行实地考察。
不少业内人士希望,此次大规模的摸底和调研后,P2P平台的主要监管部门可以尽快确定,而相关的规范文件也将出台。

Java多线程中的同步(synchronized)与锁


一段synchronized的代码被一个线程执行之前,他要先拿到执行这段代码的权限,在 java里边就是拿到某个同步对象的锁(一个对象只有一把锁); 如果这个时候同步对象的锁被其他线程拿走了,他(这个线程)就只能等了(线程阻塞在锁池 等待队列中)。 取到锁后,他就开始执行同步代码(被synchronized修饰的代码);线程执行完同步代码后马上就把锁还给同步对象,其他在锁池中 等待的某个线程就可以拿到锁执行同步代码了。这样就保证了同步代码在统一时刻只有一个线程在执行。
众所周知,在Java多线程编程中,一个非常重要的方面就是线程的同步问题。
关于线程的同步,一般有以下解决方法:

1. 在需要同步的方法的方法签名中加入synchronized关键字。

2. 使用synchronized块对需要进行同步的代码段进行同步。

3. 使用JDK 5中提供的java.util.concurrent.lock包中的Lock对象。

另外,为了解决多个线程对同一变量进行访问时可能发生的安全性问题,我们不仅可以采用同步机制,更可以通过JDK 1.2中加入的ThreadLocal来保证更好的并发性。

本篇中,将详细的讨论Java多线程同步机制,并对ThreadLocal做出探讨。

大致的目录结构如下:

一、线程的先来后到——问题的提出:为什么要有多线程同步?Java多线程同步的机制是什么?
二、给我一把锁,我能创造一个规矩——传统的多线程同步编程方法有哪些?他们有何异同?
三、Lock来了,大家都让开—— Java并发框架中的Lock详解。
四、你有我有全都有—— ThreadLocal如何解决并发安全性?
五、总结——Java线程安全的几种方法对比。


一、线程的先来后到

我 们来举一个Dirty的例子:某餐厅的卫生间很小,几乎只能容纳一个人如厕。为了保证不受干扰,如厕的人进入卫生间,就要锁上房门。我们可以把卫生间想 象成是共享的资源,而众多需要如厕的人可以被视作多个线程。假如卫生间当前有人占用,那么其他人必须等待,直到这个人如厕完毕,打开房门走出来为止。这就 好比多个线程共享一个资源的时候,是一定要分出先来后到的。

有人说:那如果我没有这道门会怎样呢?让两个线程相互竞争,谁抢先了,谁就 可以先干活,这样多好阿?但是我们知道:如果厕所没有门的话,如厕的人一起涌向 厕所,那么必然会发生争执,正常的如厕步骤就会被打乱,很有可能会发生意想不到的结果,例如某些人可能只好被迫在不正确的地方施肥……

正是因为有这道门,任何一个单独进入如厕的人都可以顺利的完成他们的如厕过程,而不会被干扰,甚至发生以外的结果。这就是说,如厕的时候要讲究先来后到。


那 么在Java 多线程程序当中,当多个线程竞争同一个资源的时候,如何能够保证他们不会产生“打架”的情况呢?有人说是使用同步机制。没错,像上面这个例子,就是典型的 同步案例,一旦第一位开始如厕,则第二位必须等待第一位结束,才能开始他的如厕过程。一个线程,一旦进入某一过程,必须等待正常的返回,并退出这一过程, 下一个线程才能开始这个过程。这里,最关键的就是卫生间的门。其实,卫生间的门担任的是资源锁的角色,只要如厕的人锁上门,就相当于获得了这个锁,而当他 打开锁出来以后,就相当于释放了这个锁。

也就是说,多线程的线程同步机制实际上是靠锁的概念来控制的。那么在Java程序当中,锁是如何体现的呢?


让我们从JVM的角度来看看锁这个概念:

在Java程序运行时环境中,JVM需要对两类线程共享的数据进行协调:
1)保存在堆中的实例变量
2)保存在方法区中的类变量

这两类数据是被所有线程共享的。
(程序不需要协调保存在Java 栈当中的数据。因为这些数据是属于拥有该栈的线程所私有的。)

在java虚拟机中,每个对象和类在逻辑上都是和一个监视器相关联的。
对于对象来说,相关联的监视器保护对象的实例变量。

对于类来说,监视器保护类的类变量。

(如果一个对象没有实例变量,或者一个类没有变量,相关联的监视器就什么也不监视。)
为了实现监视器的排他性监视能力,java虚拟机为每一个对象和类都关联一个锁。代表任何时候只允许一个线程拥有的特权。线程访问实例变量或者类变量不需锁。

但是如果线程获取了锁,那么在它释放这个锁之前,就没有其他线程可以获取同样数据的锁了。(锁住一个对象就是获取对象相关联的监视器)

类锁实际上用对象锁来实现。当虚拟机装载一个class文件的时候,它就会创建一个java.lang.Class类的实例。当锁住一个对象的时候,实际上锁住的是那个类的Class对象。

一个线程可以多次对同一个对象上锁。对于每一个对象,java虚拟机维护一个加锁计数器,线程每获得一次该对象,计数器就加1,每释放一次,计数器就减 1,当计数器值为0时,锁就被完全释放了。

java编程人员不需要自己动手加锁,对象锁是java虚拟机内部使用的。

在java程序中,只需要使用synchronized块或者synchronized方法就可以标志一个监视区域。当每次进入一个监视区域时,java 虚拟机都会自动锁上对象或者类。

看到这里,我想你们一定都疲劳了吧?o(∩_∩)o...哈哈。让我们休息一下,但是在这之前,请你们一定要记着:
当一个有限的资源被多个线程共享的时候,为了保证对共享资源的互斥访问,我们一定要给他们排出一个先来后到。而要做到这一点,对象锁在这里起着非常重要的作用。
在上一篇中,我们讲到了多线程是如何处理共享资源的,以及保证他们对资源进行互斥访问所依赖的重要机制:对象锁。



本篇中,我们来看一看传统的同步实现方式以及这背后的原理。



很多人都知道,在Java多线程编程中,有一个重要的关键字,synchronized。但是很多人看到这个东西会感到困惑:“都说同步机制是通过对象锁来实现的,但是这么一个关键字,我也看不出来Java程序锁住了哪个对象阿?“


没错,我一开始也是对这个问题感到困惑和不解。不过还好,我们有下面的这个例程:
Java代码  收藏代码
  1. public class ThreadTest extends Thread {     
  2.      private int threadNo;     
  3.      public ThreadTest(int threadNo) {     
  4.          this.threadNo = threadNo;     
  5.      }     
  6.      public static void main(String[] args) throws Exception {     
  7.          for (int i = 1; i < 10; i++) {     
  8.             new ThreadTest(i).start();     
  9.              Thread.sleep(1);     
  10.          }     
  11.       }     
  12.        
  13.      @Override    
  14.       public synchronized void run() {     
  15.          for (int i = 1; i < 10000; i++) {     
  16.              System.out.println("No." + threadNo + ":" + i);     
  17.          }     
  18.       }     
  19.   }  

  
      这个程序其实就是让10个线程在控制台上数数,从1数到9999。理想情况下,我们希望看到一个线程数完,然后才是另一个线程开始数数。但是这个程序的执行过程告诉我们,这些线程还是乱糟糟的在那里抢着报数,丝毫没有任何规矩可言。
     但是细心的读者注意到:run方法还是加了一个synchronized关键字的,按道理说,这些线程应该可以一个接一个的执行这个run方法才对阿。
     但是通过上一篇中,我们提到的,对于一个成员方法加synchronized关键字,这实际上是以这个成员方法所在的对象本身作为对象锁。在本例中,就是 以ThreadTest类的一个具体对象,也就是该线程自身作为对象锁的。一共十个线程,每个线程持有自己 线程对象的那个对象锁。这必然不能产生同步的效果。换句话说,如果要对这些线程进行同步,那么这些线程所持有的对象锁应当是共享且唯一的!

我们来看下面的例程:

Java代码  收藏代码
  1.  public class ThreadTest2 extends Thread {     
  2.   private int threadNo; private String lock;     
  3.   public ThreadTest2(int threadNo, String lock) {     
  4.   this.threadNo = threadNo;     
  5.       this.lock = lock;   }     
  6.  public static void main(String[] args) throws Exception {     
  7.     String lock = new String("lock");     
  8.       for (int i = 1; i < 10; i++) {       
  9.    new ThreadTest2(i, lock).start();     
  10.       Thread.sleep(1);     
  11.      }     
  12.   }       
  13. public void run() {       
  14.  synchronized (lock) {     
  15.       for (int i = 1; i < 10000; i++) {     
  16.        System.out.println("No." + threadNo + ":" + i);     
  17.     }        
  18.  }       
  19.  }     
  20.  }    


        我们注意到,该程序通过在main方法启动10个线程之前,创建了一个String类型的对象。并通过ThreadTest2的构造函数,将这个对象赋值 给每一个ThreadTest2线程对象中的私有变量lock。根据Java方法的传值特点,我们知道,这些线程的lock变量实际上指向的是堆内存中的 同一个区域,即存放main函数中的lock变量的区域。
        程序将原来run方法前的synchronized关键字去掉,换用了run方法中的一个synchronized块来实现。这个同步块的对象锁,就是 main方法中创建的那个String对象。换句话说,他们指向的是同一个String类型的对象,对象锁是共享且唯一的!

于是,我们看到了预期的效果:10个线程不再是争先恐后的报数了,而是一个接一个的报数。

再来看下面的例程:

Java代码  收藏代码
  1. public class ThreadTest3 extends Thread {     
  2.      
  3.     private int threadNo;     
  4.     private String lock;     
  5.      
  6.     public ThreadTest3(int threadNo) {     
  7.         this.threadNo = threadNo;     
  8.     }     
  9.      
  10.     public static void main(String[] args) throws Exception {     
  11.          
  12.         for (int i = 1; i < 20; i++) {     
  13.             new ThreadTest3(i).start();     
  14.             Thread.sleep(1);     
  15.         }     
  16.     }     
  17.      
  18.     public static synchronized void abc(int threadNo) {     
  19.         for (int i = 1; i < 10000; i++) {     
  20.                 
  21.                 System.out.println("No." + threadNo + ":" + i);             
  22.         }     
  23.     }     
  24.      
  25.     public void run() {     
  26.         abc(threadNo);     
  27.     }     
  28. }  


  •   
    细心的读者发现了:这段代码没有使用main方法中创建的String对象作为这10个线程的线程锁。而是通过在run方法中调用本线 程中一个静态的同步 方法abc而实现了线程的同步。我想看到这里,你们应该很困惑:这里synchronized静态方法是用什么来做对象锁的呢?



    我们知道,对于同步静态方法,对象锁就是该静态放发所在的类的Class实例,由于在JVM中,所有被加载的类都有唯一的类对象,具体到本例,就是唯一的 ThreadTest3.class对象。不管我们创建了该类的多少实例,但是它的类实例仍然是一个!



    这样我们就知道了:

    1、对于同步的方法或者代码块来说,必须获得对象锁才能够进入同步方法或者代码块进行操作;


    2、如果采用method级别的同步,则对象锁即为method所在的对象,如果是静态方法,对象锁即指method所在的
    Class对象(唯一);


    3、对于代码块,对象锁即指synchronized(abc)中的abc;


    4、因为第一种情况,对象锁即为每一个线程对象,因此有多个,所以同步失效,第二种共用同一个对象锁lock,因此同步生效,第三个因为是
    static因此对象锁为ThreadTest3的class 对象,因此同步生效。

    如上述正确,则同步有两种方式,同步块和同步方法(为什么没有wait和notify?这个我会在补充章节中做出阐述)

    如果是同步代码块,则对象锁需要编程人员自己指定,一般有些代码为synchronized(this)只有在单态模式才生效;
    (本类的实例有且只有一个)

    如果是同步方法,则分静态和非静态两种 。

    静态方法则一定会同步,非静态方法需在单例模式才生效,推荐用静态方法(不用担心是否单例)。

    所以说,在Java多线程编程中,最常见的synchronized关键字实际上是依靠对象锁的机制来实现线程同步的。
    我们似乎可以听到synchronized在向我们说:“给我一把 锁,我能创造一个规矩”。


    <转:http://enetor.iteye.com/blog/986623 >
分类: Java