详解Java Slipped Conditions

 更新时间:2021-01-22 09:55:41   作者:佚名   我要评论(0)

所谓Slipped conditions,就是说, 从一个线程检查某一特定条件到该线程操作此条件期间,这个条件已经被其它线程改变,导致第一个线程在该条

所谓Slipped conditions,就是说, 从一个线程检查某一特定条件到该线程操作此条件期间,这个条件已经被其它线程改变,导致第一个线程在该条件上执行了错误的操作。这里有一个简单的例子:

public class Lock {
  private boolean isLocked = true;
  public void lock(){
   synchronized(this){
    while(isLocked){
     try{
      this.wait();
     } catch(InterruptedException e){
      //do nothing, keep waiting
     }
    }
   }
   synchronized(this){
    isLocked = true;
   }
  }
  public synchronized void unlock(){
   isLocked = false;
   this.notify();
  }
}

我们可以看到,lock()方法包含了两个同步块。第一个同步块执行wait操作直到isLocked变为false才退出,第二个同步块将isLocked置为true,以此来锁住这个Lock实例避免其它线程通过lock()方法。

我们可以设想一下,假如在某个时刻isLocked为false, 这个时候,有两个线程同时访问lock方法。如果第一个线程先进入第一个同步块,这个时候它会发现isLocked为false,若此时允许第二个线程执行,它也进入第一个同步块,同样发现isLocked是false。现在两个线程都检查了这个条件为false,然后它们都会继续进入第二个同步块中并设置isLocked为true。

这个场景就是slipped conditions的例子,两个线程检查同一个条件, 然后退出同步块,因此在这两个线程改变条件之前,就允许其它线程来检查这个条件。换句话说,条件被某个线程检查到该条件被此线程改变期间,这个条件已经被其它线程改变过了。

为避免slipped conditions,条件的检查与设置必须是原子的,也就是说,在第一个线程检查和设置条件期间,不会有其它线程检查这个条件。

解决上面问题的方法很简单,只是简单的把isLocked = true这行代码移到第一个同步块中,放在while循环后面即可:

public class Lock {
  private boolean isLocked = true;
  public void lock(){
   synchronized(this){
    while(isLocked){
     try{
      this.wait();
     } catch(InterruptedException e){
      //do nothing, keep waiting
     }
    }
    isLocked = true;
   }
  }
  public synchronized void unlock(){
   isLocked = false;
   this.notify();
  }
}

现在检查和设置isLocked条件是在同一个同步块中原子地执行了。

一个更现实的例子

也许你会说,我才不可能写这么挫的代码,还觉得slipped conditions是个相当理论的问题。但是第一个简单的例子只是用来更好的展示slipped conditions。

饥饿和公平中实现的公平锁也许是个更现实的例子。再看下嵌套管程锁死中那个幼稚的实现,如果我们试图解决其中的嵌套管程锁死问题,很容易产生slipped conditions问题。首先让我们看下嵌套管程锁死中的例子:

//Fair Lock implementation with nested monitor lockout problem
public class FairLock {
 private boolean isLocked = false;
 private Thread lockingThread = null;
 private List waitingThreads =
      new ArrayList();
 public void lock() throws InterruptedException{
  QueueObject queueObject = new QueueObject();
  synchronized(this){
   waitingThreads.add(queueObject);
   while(isLocked || waitingThreads.get(0) != queueObject){
    synchronized(queueObject){
     try{
      queueObject.wait();
     }catch(InterruptedException e){
      waitingThreads.remove(queueObject);
      throw e;
     }
    }
   }
   waitingThreads.remove(queueObject);
   isLocked = true;
   lockingThread = Thread.currentThread();
  }
 }
 public synchronized void unlock(){
  if(this.lockingThread != Thread.currentThread()){
   throw new IllegalMonitorStateException(
    "Calling thread has not locked this lock");
  }
  isLocked   = false;
  lockingThread = null;
  if(waitingThreads.size() > 0){
   QueueObject queueObject = waitingThread.get(0);
   synchronized(queueObject){
    queueObject.notify();
   }
  }
 }
}1public class QueueObject {}

我们可以看到synchronized(queueObject)及其中的queueObject.wait()调用是嵌在synchronized(this)块里面的,这会导致嵌套管程锁死问题。为避免这个问题,我们必须将synchronized(queueObject)块移出synchronized(this)块。移出来之后的代码可能是这样的:

//Fair Lock implementation with slipped conditions problem
public class FairLock {
 private boolean isLocked = false;
 private Thread lockingThread = null;
 private List waitingThreads =
      new ArrayList();
 public void lock() throws InterruptedException{
  QueueObject queueObject = new QueueObject();
  synchronized(this){
   waitingThreads.add(queueObject);
  }
  boolean mustWait = true;
  while(mustWait){
   synchronized(this){
    mustWait = isLocked || waitingThreads.get(0) != queueObject;
   }
   synchronized(queueObject){
    if(mustWait){
     try{
      queueObject.wait();
     }catch(InterruptedException e){
      waitingThreads.remove(queueObject);
      throw e;
     }
    }
   }
  }
  synchronized(this){
   waitingThreads.remove(queueObject);
   isLocked = true;
   lockingThread = Thread.currentThread();
  }
 }
}

注意:因为我只改动了lock()方法,这里只展现了lock方法。

现在lock()方法包含了3个同步块。

第一个,synchronized(this)块通过mustWait = isLocked || waitingThreads.get(0) != queueObject检查内部变量的值。

第二个,synchronized(queueObject)块检查线程是否需要等待。也有可能其它线程在这个时候已经解锁了,但我们暂时不考虑这个问题。我们就假设这个锁处在解锁状态,所以线程会立马退出synchronized(queueObject)块。

第三个,synchronized(this)块只会在mustWait为false的时候执行。它将isLocked重新设回true,然后离开lock()方法。

设想一下,在锁处于解锁状态时,如果有两个线程同时调用lock()方法会发生什么。首先,线程1会检查到isLocked为false,然后线程2同样检查到isLocked为false。接着,它们都不会等待,都会去设置isLocked为true。这就是slipped conditions的一个最好的例子。

解决Slipped Conditions问题

要解决上面例子中的slipped conditions问题,最后一个synchronized(this)块中的代码必须向上移到第一个同步块中。为适应这种变动,代码需要做点小改动。下面是改动过的代码:

//Fair Lock implementation without nested monitor lockout problem,
//but with missed signals problem.
public class FairLock {
 private boolean isLocked = false;
 private Thread lockingThread = null;
 private List waitingThreads =
      new ArrayList();
 public void lock() throws InterruptedException{
  QueueObject queueObject = new QueueObject();
  synchronized(this){
   waitingThreads.add(queueObject);
  }
  boolean mustWait = true;
  while(mustWait){
   synchronized(this){
    mustWait = isLocked || waitingThreads.get(0) != queueObject;
    if(!mustWait){
     waitingThreads.remove(queueObject);
     isLocked = true;
     lockingThread = Thread.currentThread();
     return;
    }
   }  
   synchronized(queueObject){
    if(mustWait){
     try{
      queueObject.wait();
     }catch(InterruptedException e){
      waitingThreads.remove(queueObject);
      throw e;
     }
    }
   }
  }
 }
}

我们可以看到对局部变量mustWait的检查与赋值是在同一个同步块中完成的。还可以看到,即使在synchronized(this)块外面检查了mustWait,在while(mustWait)子句中,mustWait变量从来没有在synchronized(this)同步块外被赋值。当一个线程检查到mustWait是false的时候,它将自动设置内部的条件(isLocked),所以其它线程再来检查这个条件的时候,它们就会发现这个条件的值现在为true了。

synchronized(this)块中的return;语句不是必须的。这只是个小小的优化。如果一个线程肯定不会等待(即mustWait为false),那么就没必要让它进入到synchronized(queueObject)同步块中和执行if(mustWait)子句了。

细心的读者可能会注意到上面的公平锁实现仍然有可能丢失信号。设想一下,当该FairLock实例处于锁定状态时,有个线程来调用lock()方法。执行完第一个 synchronized(this)块后,mustWait变量的值为true。再设想一下调用lock()的线程是通过抢占式的,拥有锁的那个线程那个线程此时调用了unlock()方法,但是看下之前的unlock()的实现你会发现,它调用了queueObject.notify()。但是,因为lock()中的线程还没有来得及调用queueObject.wait(),所以queueObject.notify()调用也就没有作用了,信号就丢失掉了。如果调用lock()的线程在另一个线程调用queueObject.notify()之后调用queueObject.wait(),这个线程会一直阻塞到其它线程调用unlock方法为止,但这永远也不会发生。

公平锁实现的信号丢失问题在饥饿和公平一文中我们已有过讨论,把QueueObject转变成一个信号量,并提供两个方法:doWait()和doNotify()。这些方法会在QueueObject内部对信号进行存储和响应。用这种方式,即使doNotify()在doWait()之前调用,信号也不会丢失。

以上就是详解Java Slipped Conditions的详细内容,更多关于Java Slipped Conditions的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
  • Java 内存溢出的原因和解决方法
  • Java虚拟机常见内存溢出错误汇总
  • 详解Java内存溢出的几种情况
  • Java虚拟机内存溢出与内存泄漏
  • Java内存溢出实现原因及解决方案
  • Java 堆内存溢出原因分析
  • Java堆内存又溢出了!教你一招必杀技(推荐)
  • 解决Java导入excel大量数据出现内存溢出的问题
  • Java编程常见内存溢出异常与代码示例
  • 完美解决java读取大文件内存溢出的问题

相关文章

  • 详解Java Slipped Conditions

    详解Java Slipped Conditions

    所谓Slipped conditions,就是说, 从一个线程检查某一特定条件到该线程操作此条件期间,这个条件已经被其它线程改变,导致第一个线程在该条
    2021-01-22
  • nodejs中使用worker_threads来创建新的线程的方法

    nodejs中使用worker_threads来创建新的线程的方法

    简介 之前的文章中提到了,nodejs中有两种线程,一种是event loop用来相应用户的请求和处理各种callback。另一种就是worker pool用来处理各种
    2021-01-22
  • 在idea中使用JaCoCo插件统计单元测试覆盖率的实现

    在idea中使用JaCoCo插件统计单元测试覆盖率的实现

    在后台工程师开发完新代码交给QA进行测试时,软件测试人员一般都会要求后台开发对单元测试的覆盖率达到一定的标准;例如我们的标准是分支覆盖
    2021-01-22
  • SpringCloud手写Ribbon实现负载均衡

    SpringCloud手写Ribbon实现负载均衡

    前言 前面我们学习了 SpringCloud整合Consul ,在此基础上我们手写本地客户端实现类似Ribbon负载均衡的效果。 注: order 模块调用者 记得关
    2021-01-22
  • 如何使用C#中的Lazy的使用方法

    如何使用C#中的Lazy的使用方法

    延迟初始化 是一种将对象的创建延迟到第一次需要用时的技术,换句话说,对象的初始化是发生在真正需要的时候才执行,值得注意的是,术语 延迟
    2021-01-22
  • 最优雅地整合 Spring & Spring MVC & MyBatis 搭建 Java 企业级应用(附源码)

    最优雅地整合 Spring & Spring MVC & MyBatis 搭建 Java 企业级应用(附源码)

    这里使用 Maven 项目管理工具构建项目 初始化项目 打开 Intellij IDEA,点击 Create New Project 选择 Maven 构建项目 选择 JDK 版本
    2021-01-22
  • Android使用TypeFace设置TextView的文字字体

    Android使用TypeFace设置TextView的文字字体

    在Android里面设置一个TextView的文字颜色和文字大小,都很简单,也是一个常用的基本功能。但很少有设置文字字体的,今天要分享的是通过Type
    2021-01-22
  • IDEA 单元测试覆盖技巧分享

    IDEA 单元测试覆盖技巧分享

    1.前言 通常情况下,项目经理or项目总监会分阶段的问测试负责人,本阶段的测试覆盖率是多少?在工作中,当被问到“如何提高代码质量”,回答
    2021-01-22
  • Java信号量全解析

    Java信号量全解析

    前言: Semaphore(信号量) 是一个线程同步结构,用于在线程间传递信号,以避免出现信号丢失(译者注:下文会具体介绍),或者像锁一样用
    2021-01-22
  • 在eclipse中修改tomcat的部署路径操作

    在eclipse中修改tomcat的部署路径操作

    在eclipse上面部署web项目后,它没有将你的项目文件放到tomcat 的目录下面。而是放在了你的工作目录下面。 你到这里去找:E:\jintao\.metada
    2021-01-22

最新评论