zoukankan      html  css  js  c++  java
  • 多线程编程之保护性暂挂模式

           保护性暂挂模式,也称为Guarded Suspension模式,指的是当前线程在执行某个任务之前,需要检查某一条件,只有在该条件成立的情况下,当前线程才可以继续往下执行当前任务。顾名思义,保护性暂挂模式是一种广义的概念,其主要载体有两个:预备条件和任务,在任何需要使用预先检查的情况中都可以使用保护性暂挂模式。

    1. 角色描述

    保护性暂挂类图

           如下是类图中各个角色定位的描述:

    • GuardedObject:受保护的对象,供给客户端调用,用于生成并执行受保护的行为的和检查并控制状态改变的,如下是其各个方法的作用:
      • guardedMethod():生成并且执行受保护的行为;
      • stateOperation():用于检查当前状态是否满足特定的状态,从而控制受保护行为的状态;
    • Blocker:该类主要提供了一些模板方法,主要是用于调用受保护行为,或者唤醒当前由于先验条件不通过而导致等待的线程的,如下是其各个方法的作用:
      • callWithGuard(GuardedAction):该方法首先会检查GuardedAction提供的先验条件是否满足,如果不满足,则会阻塞当前线程,否则会执行GuardedAction中的任务;
      • signalAfter(Callable):该方法会先检查先验条件是否满足,如果满足先验条件则会唤醒一个正在等待的线程;
      • broadcastAfter(Callable):该方法会先检查先验条件是否满足,如果先验条件满足则会唤醒所有正在等待的线程;
      • signal:直接唤醒一个正在等待先验条件满足的线程;
      • broadcast():直接唤醒所有正在等待先验条件满足的线程;
    • GuardedAction:受保护方法的载体,并且提供了进行先验检查的条件,其各方法和属性作用如下:
      • predicate:提供了进行先验检查的条件;
      • call():提供了需要执行的任务;
    • Predicate:承载了进行先验条件检查的条件。

    2. 实例演示

           比如我们会遇到这种场景,在进行某些操作时,比如通过elasticsearch服务器进行查询或更新操作,我们需要连接es服务器,而在es服务器连接上之前,所有的查询和更新操作都是需要被阻塞的。即使在服务器连接上之后,我们也需要经常对服务器进行心跳测试,以检查与服务器的连接是否还存活在,如果不存活,则还是需要继续阻塞其余的操作,并且尝试重新连接es服务器,这种情况我们就可以使用到保护性暂挂模式。保护性条件即是与es服务器的连接还存活在,如果不存活则需要挂起所有尝试连接服务器执行任务的线程,并且当前线程会尝试连接服务器。如下是示例代码:

    public class ElasticSearchAgent {
      private volatile boolean connectedToServer = false;
    
      private final Predicate agentConnected = () -> connectedToServer;
    
      private final Blocker blocker = new ConditionVarBlocker();
    
      private final Timer heartbeatTimer = new Timer(true);
    
      public void update(final UpdateCondition condition) throws Exception {
        GuardedAction<Void> guardedAction = new GuardedAction<Void>(agentConnected) {
          @Override
          public Void call() {
            doUpdate(condition);
            return null;
          }
        };
    
        blocker.callWithGuard(guardedAction);
      }
    
      private void doUpdate(UpdateCondition condition) {
        try {
          TimeUnit.MICROSECONDS.sleep(20); // 模拟进行更新
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }
    
      public void init() {
        Thread connectingThread = new Thread(new ConnectingTask());
        connectingThread.start();
        heartbeatTimer.schedule(new HeartBeatTask(), 60000, 2000);
      }
    
      public void disconnect() {
        connectedToServer = false;
      }
    
      protected void onConnected() {
        try {
          blocker.signalAfter(() -> {
            connectedToServer = true;
            return Boolean.TRUE;
          });
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
    
      protected void onDisconnected() {
        connectedToServer = false;
      }
    
      private class ConnectingTask implements Runnable {
        @Override
        public void run() {
          try {
            Thread.sleep(100);
          } catch (InterruptedException e) {}
    
          onConnected();
        }
      }
    
      private class HeartBeatTask extends TimerTask {
    
        @Override
        public void run() {
          if (!testConnection()) {
            onDisconnected();
            reconnect();
          }
        }
    
        private boolean testConnection() {
          return true;
        }
    
        private void reconnect() {
          ConnectingTask connectingTask = new ConnectingTask();
          connectingTask.run();
        }
      }
    }
    

           可以看到,在进行update()操作时,首先会创建一个GuardedAction对象,真正的更新操作是在该对象中进行的,这里的保护性条件是通过一个volatile类型的变量connectedToServer来控制的,如果当前与es服务器的连接还存活在,则该变量置为true。HeartBeatTask是一个定时任务,在60s延迟之后每隔2s会向服务器发送心跳测试,以检查连接是否存活,如果不存活,则会将connectedToServer变量置为false,并且会尝试连接服务器。在init()方法中首先会创建一个连接服务器的任务,以保证服务器连接在初始时的可用状态,并且其还会启动心跳测试的定时任务。如下是Blocker和ConditionVarBlocker的实现代码:

    public interface Blocker {
      <V> V callWithGuard(GuardedAction<V> guardedAction) throws Exception;
    
      void signalAfter(Callable<Boolean> stateOperation) throws Exception;
    
      void signal() throws InterruptedException;
    
      void broadcastAfter(Callable<Boolean> stateOperation) throws Exception;
    }
    
    public class ConditionVarBlocker implements Blocker {
      private final Lock lock;
      private final Condition condition;
    
      public ConditionVarBlocker(Lock lock) {
        this.lock = lock;
        this.condition = lock.newCondition();
      }
    
      public ConditionVarBlocker() {
        this.lock = new ReentrantLock();
        this.condition = lock.newCondition();
      }
    
      @Override
      public <V> V callWithGuard(GuardedAction<V> guardedAction) throws Exception {
        lock.lockInterruptibly();
        try {
          final Predicate guard = guardedAction.guard;
          while (!guard.evaluate()) {
            condition.await();
          }
    
          return guardedAction.call();
        } finally {
          lock.unlock();
        }
      }
    
      @Override
      public void signalAfter(Callable<Boolean> stateOperation) throws Exception {
        lock.lockInterruptibly();
        try {
          if (stateOperation.call()) {
            condition.signal();
          }
        } finally {
          lock.unlock();
        }
      }
    
      @Override
      public void signal() throws InterruptedException {
        lock.lockInterruptibly();
        try {
          condition.signal();
        } finally {
          lock.unlock();
        }
      }
    
      @Override
      public void broadcastAfter(Callable<Boolean> stateOperation) throws Exception {
        lock.lockInterruptibly();
        try {
          if (stateOperation.call()) {
            condition.signalAll();
          }
        } finally {
          lock.unlock();
        }
      }
    }
    

            可以看到,ConditionVarBlocker中基本上都是模板代码,其声明了一个Lock对象和一个Condition对象,Lock对象用于对当前的先验条件检查过程进行同步处理,Condition对象则用于在先验条件不满足的情况下阻塞当前线程的。

           在callWithGuard()方法中,首先会在一个循环中检查当前的先验条件是否满足,如果不满足,则使当前线程进入等待状态,如果满足,则当前线程继续执行其任务。这里需要注意的是,我们使用了while()循环用于判断先验条件是否满足,因为有可能当前线程被意外的唤醒,或者说被唤醒之后先验条件还是不满足,因而这里使用循环判断,以使当前线程在先验条件不满足的情况下继续等待。

           在signalAfter()方法中,其首先调用stateOperation.call()方法,判断当前的先验条件是否满足,只有在先验条件满足的情况下才会唤醒一个等待的线程。这里stateOperation是ElasticSearchAgent传入的用于判断当前是否处于连接状态的一个条件载体。

           如下是GuardedAction的实现代码:

    public abstract class GuardedAction<V> implements Callable<V> {
      protected final Predicate guard;
    
      public GuardedAction(Predicate guard) {
        this.guard = guard;
      }
    }
    

           这里GuardedAction是一个抽象类,其主要封装了一个Predicate属性。GuardedAction的主要实现在ElasticSearchAgent.guardedMethod()方法中生成的,因为具体需要执行的任务需要调用方生成,这里只是提供了一个模板方法。如下是Predicate的代码:

    @FunctionalInterface
    public interface Predicate {
      boolean evaluate();
    }
    

           这里Predicate也只是一个声明而已,其具体的实现也是在ElasticSearchAgent中,本例中主要是判断connectedToServer是否为true,即处于连接服务器的状态。

    3. Guarded Suspension实现考量

    • 可以看到Guarded Suspension的实现中,Blocker、GuardedAction和Predicate只是提供的一个模板,其内主要是一些通用的代码,而和具体业务相关的代码主要在ElasticSearchAgent中,其会创建所需执行的GuardedAction对象,并且控制其所需的先验条件。Guarded Suspension将关注点进行了分离,我们在使用该模式的时候主要需要实现的也即是类似于ElasticSearchAgent的一个客户端类;
    • 在执行使用Guarded Suspension模式的时候,需要注意的是,每次执行GuardedObject.guardedMethod()方法时都会创建一个GuardedAction对象,这可能会对JVM垃圾回收造成一定的负担,因而在使用该模式时如果内存较小需要特别注意该问题;
    • 在Guarded Suspension模式中,ConditionVarBlocker的callWithGuard()和signal*()方法的执行都进行了加锁处理,这是因为ConditionVarBlocker是所有线程所共有的一个对象,其lock和condition变量是需要所有线程都一致可见的,因而这里需要对其进行加锁处理;
    • 在ConditionVarBlocker.callWithGuard()方法中,对先验条件的检查是使用一个while循环进行的,这是为了防止等待的线程被意外的唤醒,而先验条件此时还不满足,使用while循环就可以保证当前线程再次进入到等待状态;
    • 上述ConditionVarBlocker还提供了一个如下的构造方法:
    public ConditionVarBlocker(Lock lock) {
        this.lock = lock;
        this.condition = lock.newCondition();
    }
    

    该方法用于防止ElasticSearchAgent由于某种原因而需要加锁时可能会造成嵌套监视器锁死的问题的。所谓的嵌套监视器锁死的问题指的是,如果某个线程执行依次获取了两个锁,而由于先验条件不满足,从而导致当前线程释放了内层锁从而进入等待状态,而另外的线程为了检查当前的先验条件需要获取到外层锁,这就导致了锁循环等待的问题,在等待先验条件满足的线程持有外层锁,其无法释放,而尝试改变先验条件的线程正在尝试获取外层锁,但其一直无法获取到,从而造成了死锁。这种情况下就提供了该构造方法,如果ElasticSearchAgent需要对其方法进行加锁,那么其需要通过该构造方法将锁传递给ConditionVarBlocker,这样当前线程在释放锁的时候就会将外层锁和内层锁同时释放了(因为都是同一个锁)。

  • 相关阅读:
    poj 2312 Battle City
    poj 2002 Squares
    poj 3641 Pseudoprime numbers
    poj 3580 SuperMemo
    poj 3281 Dining
    poj 3259 Wormholes
    poj 3080 Blue Jeans
    poj 3070 Fibonacci
    poj 2887 Big String
    poj 2631 Roads in the North
  • 原文地址:https://www.cnblogs.com/zhangxufeng/p/9162172.html
Copyright © 2011-2022 走看看