多线程设计模式5-single threaded Execution模式(附分布式环境下的操作)

多线程设计模式5-single threaded Execution模式(附分布式环境下的操作)

single threaded Execution模式主要是用于确保同一时间内只能让一个线程执行处理,说通俗点就是对synchronized的标准化使用方式,这是比较基础的,所以我们前面重点介绍下如何保证同一个Jvm进程内的多线程同步,后面扩展开来,保证多个Jvm进程间多线程同步(分布式环境)。两者有很大的相似性。

单jvm进程下:

先看下一个简单的例子:

public class Ticket {

  private int counter = 100;

  public  void dec() {
    if(counter>0) {
      System.out.println(Thread.currentThread().getName() + "号窗口卖出:" + this.counter-- + "号票");
    }else{
      System.out.println("票已售完");
    }
  }

}

public class StationThread  extends Thread{
  Ticket ticket;

  public StationThread(Ticket ticket) {
    this.ticket = ticket;
  }
  @Override
  public void run() {
    while (true) {
      try{
        Thread.sleep(500);
      }catch(InterruptedException e){
        e.printStackTrace();
      }
      ticket.dec();
    }
  }

}


public class Main {

  public static void main(String[] args) {
    System.out.println("Testing...");
    Ticket ticket = new Ticket();
    new StationThread(ticket).start();
    new StationThread(ticket).start();
    new StationThread(ticket).start();
  }
}

这里打印结果可知,执行明显是错误的:

Testing...
Thread-0号窗口卖出:100号票
Thread-1号窗口卖出:99号票
Thread-2号窗口卖出:98号票
Thread-1号窗口卖出:97号票
Thread-2号窗口卖出:97号票
Thread-0号窗口卖出:97号票
Thread-2号窗口卖出:96号票
Thread-1号窗口卖出:96号票
Thread-0号窗口卖出:96号票
......

为什么会出错呢?因为Ticket不是线程安全的,this.counter—并不是一个原子性的操作,其中包含了读取,修改,写入,多个线程执行的时候,这些命令会交错执行,导致执行结果与预期不一致。

接下来,我们改下Ticket的方法:

 public synchronized void dec() {
    if(counter>0) {
      System.out.println(Thread.currentThread().getName() + "号窗口卖出:" + this.counter-- + "号票");
    }else{
      System.out.println("票已售完");
    }
  }

添加了synchronized后,执行结果正常:

Testing...
Thread-0号窗口卖出:100号票
Thread-1号窗口卖出:99号票
Thread-2号窗口卖出:98号票
Thread-0号窗口卖出:97号票
Thread-1号窗口卖出:96号票
Thread-2号窗口卖出:95号票
Thread-0号窗口卖出:94号票
Thread-1号窗口卖出:93号票
Thread-2号窗口卖出:92号票
Thread-1号窗口卖出:91号票
Thread-2号窗口卖出:90号票
Thread-0号窗口卖出:89号票
Thread-1号窗口卖出:88号票
Thread-0号窗口卖出:87号票
Thread-2号窗口卖出:86号票
Thread-1号窗口卖出:85号票
Thread-2号窗口卖出:84号票
Thread-0号窗口卖出:83号票
Thread-1号窗口卖出:82号票
Thread-2号窗口卖出:81号票
Thread-0号窗口卖出:80号票
Thread-1号窗口卖出:79号票
Thread-2号窗口卖出:78号票
Thread-0号窗口卖出:77号票
......

synchronized保证了方法只能由一个线程,防止了由多个线程交错执行的情况。我们知道,编写线程安全的代码,核心在于对状态访问操作进行管理,特别是共享和可变的状态,这里Ticket就是一个共享资源(SharedResource),通过single thread execution模式,将非安全的方法声明为synchronized方法,确保同一时间只被一个线程访问。

使用时注意事项:

1、死锁问题:

死锁指多个线程同时被阻塞,它们中的一个或者全部都在等待某个资源被释放。由于线程被无限期地阻塞,因此程序不可能正常终止。就如同一座桥,只能容纳一辆车,有两辆车,相向而行,分到桥的中途,需要占据对方的空间才能通过。因此,就一直处于阻塞状态。

死锁主要是由于多个线程加锁顺序不一致导致的,可以从这里角度分析,防止死锁。

2、性能

获取锁花费时间,线程冲突会引起等待,为了提高性能,需要管理好锁的临界区,确定同步代码块的合理大小。

多jvm进程下:

分布式锁的方式:

一、通过如下命令在redis中实现分布式锁的功能

SET key value NX EX max-lock-time

其中NX是操作模式,表示只在键不存在时,才对键进行设置操作。

EX max-lock-time用于设置键的过期时间为max-lock-time秒。

这个命令连续两次执行结果如下:

test-redis:0>SET not-exists-key "value" NX EX 60
OK

test-redis:0>SET not-exists-key "value" NX EX 60
NULL

过六十秒后再执行:

test-redis:0>SET not-exists-key "value" NX EX 60
OK

这样,当一个线程执行命令成功,说明key原本不存在,该线程成功得到了锁;当设置失败时,说明key已经存在,该线程抢锁失败。

当到达过期时间,或者key被删除(del),说明锁被释放,其他线程可以继续执行这个命令来获取锁。

通过redis实现分布式锁有许多实现细节需要注意的:

1、很多人会通过setnx代替SET key value NX命令,但前者没有设置过期时间的参数,因此设置key值和设置过期时间便成为一个复合操作,不具备原子性,当一个线程设置了key值,但未设置过期时间,这时相关的节点挂了,但key一直存在,那其他线程就永远无法获取这个锁了(死锁)。

2、过期时间很难设置,如果设置短了,假设获得锁的A线程的任务还没执行完成,这时候锁就被释放了,其他线程就会获得锁,导致难以预料的一系列后果。如A线程执行完后误删了后一个线程的锁,共享数据被破坏等等。对此,我们可以通过开一个守护线程,当线程任务未执行完成,给锁续期。

二、zookeeper实现分布式锁

zookeeper分布式锁,实现更加完善,封装更好一点,因此,使用更加方便。

首先介绍下zookeeper分布式锁的实现原理。

为了构建这个锁,zookeeper创建一个持久的znode,它将作为父节点。试图获得锁的客户端将在父节点下面创建顺序的、临时的子节点。锁是由子节点具有最低的序列号的客户端进程拥有的。在图1中,锁节点有三个子节点,而节点1在这个时间点拥有锁,因为它的序列号是最低的。如果客户端创建的节点不是最小节点,就获得该节点的上一顺序节点,并给它注册watcher,同时在这里阻塞,等待监听事件的发生。当完成之后,关闭ZooKeeper连接,进而可以引发监听事件,释放该锁(在删除节点1之后,锁被释放), 然后拥有节点2的客户端拥有这个锁,以此类推。

多线程设计模式5-single threaded Execution模式(附分布式环境下的操作)_第1张图片
图1

zookeeper实现类似等待队列的机制,大大提升了抢锁的效率。

另外我们来看下,zookeeper有没有类似redis分布式锁那样的问题。我们发现它是不需要设置过期时间的,当任务完成时,客户端会删除节点,进而释放锁;当客户端挂掉,相应的临时会自动删除,锁被释放,其下一个序列的节点会收到通知,获取锁;当连接中断时则根据配置的重试机制重新连接。

Apache Curator,包含了对zookeeper分布式锁的实现,下面是使用代码,有兴趣可以研究下源码:

1、创建一个重试策略,然后使用CuratorFrameworkFactory.newClient()来获得CuratorFramework的实例

RetryPolicy retryPolicy = new ExponentialBackoffRetry(baseSleepTimeMills, maxRetries);

CuratorFramework client = CuratorFrameworkFactory.newClient(hosts, retryPolicy);

client.start();

2、为特定的锁路径(lockPath)创建一个进程互斥锁,获取锁,执行一些操作,然后释放锁。

InterProcessLock lock = new InterProcessMutex(client, lockPath);

if (lock.acquire(waitTimeSeconds, TimeUnit.SECONDS)) {

  try {

    // do work while we hold the lock

  } catch (Exception ex) {

    // handle exceptions as appropriate

  } finally {

    lock.release();

  }

} else {

  // we timed out waiting for lock, handle appropriately

}

3、不要忘记关闭client

client.close();

你可能感兴趣的:(多线程设计模式5-single threaded Execution模式(附分布式环境下的操作))