(Java 高并发程序设计) 一篇文章带你深入了解多线程中的线程阻塞工具类（LockSupport）、Guava和RateLimiter限流

Bertha 。 2022-12-22 11:20 135阅读 0赞

### 文章目录 ###

*   *  一、线程阻塞工具类：LockSupport
     *  二、Guava和RateLimiter限流

## 一、线程阻塞工具类：LockSupport ##

LockSupport 是一个非常方便实用的线程阻塞工具，它可以在线程内任意位置让线程阻塞。与`Thread.suspend()`方法相比，它弥补了由于`resume()`方法发生导致线程无法继续执行的情况。和`Object.wait()`方法相比，它不需要先获得某个对象的锁，也不会抛出`InterruptedException`异常。LockSupport 的静态方法`park()`可以阻塞当前线程，类似的还有`parkNanos()`、`parkUntil()`等方法。它们实现了一个限时的等待。

public class LockSupportDemo { 
    
        public static Object u = new Object();
        static ChangeObjectThread t1 = new ChangeObjectThread("t1");
        static ChangeObjectThread t2 = new ChangeObjectThread("t2");
    
        public static class ChangeObjectThread extends Thread { 
            public ChangeObjectThread(String name) { 
                super.setName(name);
            }
            @Override
            public void run() { 
                synchronized (u) { 
                    System.out.println("in " + getName());
                    LockSupport.park();
                }
            }
        }
    
        public static void main(String[] args) throws InterruptedException { 
            t1.start();
            Thread.sleep(100);
            t2.start();
            //
            LockSupport.unpark(t1);
            LockSupport.unpark(t2);
        }
    }

注意，这里只是将原来的`suspend()`方法和`resume()`方法用`park()`方法和`unpark()`方法做了替换。当然，我们依然无法保证`unpark()`方法发生在`park()`方法之后。但是执行这段代码，你会发现，它自始至终都可以正常地结束，不会因为`park()`方法而导致线程永久挂起。

这是因为LockSupport类使用类似信号量的机制。它为每一个线程准备了一个许可，如果许可可用，那么`park()`方法会立即返回，并且消费这个许可（也就是将许可变为不可用），如果许可不可用，就会阻塞，而`unpark()`方法则使得一个许可变为可用（但是和信号量不同的是，许可不能累加，你不可能拥有超过一个许可，它永远只有一个）

这个特点使得：即使`unpark()`方法操作发生在`park()`方法之前，它也可以使下一次的`park()`方法操作立即返回。这也就是上述代码可顺利结束的主要原因。

同时，处于`park()`方法挂起状态的线程不会像`suspend()`方法那样还给出一个令人费解的Runnable状态。它会非常明确地给出一个WAITING状态，甚至还会标注是`park()`方法引起的。

除了有定时阻塞的功能，`LockSupport.park()`方法还能支持中断影响。但是和其他接收中断的函数很不一样，`LockSupport.park()`方法不会抛出`InterruptedException`异常。它只会默默返回，但是我们可以从`Thread.interrupted()`等方法中获得中断标记。

import java.util.concurrent.locks.LockSupport;
    
    public class LockSupportIntDemo { 
    
        public static Object u = new Object();
        static ChangeObjectThread t1 = new ChangeObjectThread("t1");
        static ChangeObjectThread t2 = new ChangeObjectThread("t2");
    
        public static class ChangeObjectThread extends Thread { 
            public ChangeObjectThread(String name) { 
                super.setName(name);
            }
    
            @Override
            public void run() { 
                synchronized (u) { 
                    System.out.println("in " + getName());
                    //线程阻塞
                    LockSupport.park();
                    //线程中断
                    if (Thread.interrupted()) { 
                        System.out.println(getName() + "被中断了");
                    }
                }
                System.out.println(getName() + "执行结束");
            }
        }
    
        public static void main(String[] args) throws InterruptedException { 
            t1.start();
            Thread.sleep(100);
            t2.start();
            //中断线程t1
            t1.interrupt();
            LockSupport.unpark(t2);
        }
    }

![在这里插入图片描述][20201120102616685.png_pic_center]

## 二、Guava和RateLimiter限流 ##

Guava是Google下的一个核心库，提供了一大批设计精良、使用方便的工具类。许多Java项目都使用Guava作为其基础工具库来提升开发效率，我们可以认为Guava是JDK标准库的重要补充。

在这里，将给大家介绍Guava中的一款限流工具`RateLimiter`。任何应用和模块组件都有一定的访问速率上限，如果请求速率突破了这个上限，不但多余的请求无法处理，甚至会压垮系统使所有的请求均无法有效处理。因此，对请求进行限流是非常必要的。`RateLimiter`正是这么一款限流工具。

一种简单的限流算法就是给出一个单位时间，然后使用一个计数器counter统计单位时间内收到的请求数量，当请求数量超过门限时，余下的请求丢弃或者等待。但这种简单的算法有一个严重的问题，就是很难控制边界时间上的请求。假设时间单位是1秒，每秒请求不超过10个。如果在这一秒的前半秒没有请求，而后半秒有10个请求，下一秒的前半秒又有10个请求，那么在这中间的一秒内，就会合理处理20个请求，而这明显违反了限流的基本需求。

这是一种简单粗暴的总数量限流而不是平均限流，如图3.3所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center]

因此，更为一般化的限流算法有两种：漏桶算法和令牌桶算法。

漏桶算法的基本思想是：利用一个缓存区，当有请求进入系统时，无论请求的速率如何，都先在缓存区内保存，然后以固定的流速流出缓存区进行处理，如图3.4所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 1]

漏桶算法的特点是无论外部请求压力如何，漏桶算法总是以固定的流速处理数据。漏桶的容积和流出速率是该算法的两个重要参数

令牌桶算法是一种反向的漏桶算法。在令牌桶算法中，桶中存放的不再是请求，而是令牌。处理程序只有拿到令牌后，才能对请求进行处理。如果没有令牌，那么处理程序要么丢弃请求，要么等待可用的令牌。为了限制流速，该算法在每个单位时间产生一定量的令牌存入桶中。比如，要限定应用每秒只能处理1个请求，那么令牌桶就会每秒产生1个令牌。通常，桶的容量是有限的，比如，当令牌没有被消耗掉时，只能累计有限单位时间内的令牌数量，其基本原理如图3.5所示。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 2]  
RateLimiter正是采用了令牌桶算法。下例展示了RateLimiter的使用方法：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 3]  
上述代码第2行限制了`RateLimiter`每秒只能处理两个请求。在第13行调用`RateLimiter`的`acquire()`方法来控制流量。执行上述代码，部分输出如下：

![在这里插入图片描述][20201120105534792.png_pic_center]  
从输出的时间戳可以看到每秒至多输出两条记录，起到了流量控制的效果。当使用`acquire()`方法时，过剩的流量调用会等待，直到有机会执行。

但在有些场景中，如果系统无法处理请求，为了保证服务质量，更倾向于直接丢弃过载请求，从而避免可能的崩溃，此时，则可以使用`tryAcquire()`方法，如下所示。

![在这里插入图片描述][20201120105612513.png_pic_center]  
当请求成功时，`tryAcquire()`方法返回true，否则返回false，该方法不会阻塞。在本段代码中，如果访问数据量超过限制，那么超出部分则直接丢弃，不再进行处理。根据前文的描述，limiter仅支持1秒两次调用。也就是每500毫秒可以产生一个令牌，显然由于for循环本身的效率很高，完全可以在500毫秒内完成，因此本段代码最终只产生一个输出，其余请求全部被丢弃。

[20201120102616685.png_pic_center]: /images/20221120/6501336f65764fbe8a95be7ed1e92ef0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/829a47f7de52482082ec7a8f447fd225.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/7743a19d01bf4601bc12cb4c94e84e42.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/ce1c37374f46473caa50ac26aff25c65.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmh1YWliZWlhbg_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/9a0d922817274977ad9239180c164e40.png
[20201120105534792.png_pic_center]: /images/20221120/cda62129856c44e2b1ad7702e24080bd.png
[20201120105612513.png_pic_center]: /images/20221120/086a87de5e61416ea1c12092bc012b38.png