JDK对容器的支持和限制

Posted IT职场笔记

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了JDK对容器的支持和限制相关的知识,希望对你有一定的参考价值。

容器毕竟是一种轻量级的实现方式,所以其封闭性不如虚拟机技术。

1、容器环境的资源隔离性

举个例子:

物理机/宿主机有 96 个 CPU 内核、256GB 物理内存,容器限制的资源是 4 核 8G,那么容器内部的 JVM 进程看到的内核数和内存数是多少呢?
目前来说,JVM 看到的内核数是 96,内存值是 256G。

这会造成一些问题,基于 CPU 内核数 availableProcessors 的各种算法都会受到影响,比如默认 GC 线程数:假如啥都不配置,JVM 看见 96 个内核,设置 GC 并行线程数为 96*5/8~=60,但容器限制了只能使用 4 个内核资源,于是 60 个并行 GC 线程来争抢 4 个机器内核,造成严重的 GC 性能问题。

同样的道理,很多线程池的实现,根据内核数量来设置并发线程数,也会造成剧烈的资源争抢。如果容器不限制资源的使用也会造成一些困扰,比如下面介绍的坏邻居效应。基于物理内存 totalPhysicalMemorySize 和空闲内存 freePhysicalMemorySize 等配置信息的算法也会产生一些奇怪的 Bug。

  

2、JDK 对容器的支持和限制

最新版的 JDK 加入了一些修正手段。

新版 JDK 支持 Docker 容器的 CPU 和内存限制:

可以增加 JVM 启动参数来读取 Cgroups 对 CPU 的限制:

Hotspot 是一个规范的开源项目,关于 JDK 的新特性,可以阅读官方的邮件订阅,例如:

其他版本的 JDK 特性,也可以按照类似的命名规范,从官网的 Mailing Lists 中找到:

关于这个问题的排查和分析,请参考前面的章节[《JVM 问题排查分析调优经验》]。

 

3、坏邻居效应

有共享资源的地方,就会有资源争用。在计算机领域,共享的资源主要包括:

  • 网络
  • 磁盘
  • CPU
  • 内存

在多租户的公有云环境中,会存在一种严重的问题,称为“坏邻居效应”(noisy neighbor phenomenon)。当一个或多个客户过度使用了某种公共资源时,就会明显损害到其他客户的系统性能。(就像是小区宽带一样)

 

吵闹的坏邻居(noisy neighbor),用于描述云计算领域中,用来描述抢占共有带宽,磁盘 I/O、CPU 以及其他资源的行为。

 

坏邻居效应,对同一环境下的其他虚拟机/应用的性能会造成影响或抖动。一般来说,会对其他用户的性能和体验造成恶劣的影响。

 

云,是一种多租户环境,同一台物理机,会共享给多个客户来运行程序/存储数据。

坏邻居效应产生的原因,是某个虚拟机/应用霸占了大部分资源,进而影响到其他客户的性能。

带宽不足是造成网络性能问题的主要原因。在网络中传输数据严重依赖带宽的大小,如果某个应用或实例占用太多的网络资源,很可能对其他用户造成延迟/缓慢。坏邻居会影响虚拟机、数据库、网络、存储以及其他云服务。

 

有一种避免坏邻居效应的方法,是使用裸机云(bare-metal cloud)。裸机云在硬件上直接运行一个应用,相当于创建了一个单租户环境,所以能消除坏邻居。虽然单租户环境避免了坏邻居效应,但并没有解决根本问题。超卖(over-commitment)或者共享给太多的租户,都会限制整个云环境的性能。

 

另一种避免坏邻居效应的方法,是通过在物理机之间进行动态迁移,以保障每个客户获得必要的资源。此外,还可以通过 存储服务质量保障(QoS,quality of service)控制每个虚拟机的 IOPS,来限制坏邻居效应。通过 IOPS 来限制每个虚拟机使用的资源量,就不会造成某个客户的虚机/应用/实例去挤占其他客户的资源/性能。

 

有兴趣的同学可以查看:

[谈谈公有云的坏邻居效应](https://github.com/cncounter/translation/blob/master/tiemao_2016/45_noisy_neighbors/noisy_neighbor_cloud _performance.md)

Java 并发编程 - 3

 

JDK 1.5 之前的同步容器

JDK 1.5 之前, 主要包括:

  • 同步容器 (Vector 和 Hashtable)
  • 同步包装类 (Collections.synchronizedXxx)

这些类的共同特征是, 公共方法都是由 synchronized 来修饰的, 以限制一次只能有一个线程能访问容器.

同步容器中出现的问题

复合操作

老的容器自身并不支持复合操作, 包括:

  1. 迭代(反复获取元素, 直到获得容器中的最后一个元素)
  2. 导航(navigation, 根据一定的顺序寻找下一个元素)
  3. 条件运算(check-then-act)

好在老的容器类遵循一个支持 客户端加锁 的同步策略. 来解决复合运算的问题:

  • 解决迭代和导航:

    synchronized(list) { // 确保调用 size() 后, list 大小不会改变
        for (int i = 0; i < list.size(); ++i) {
            doSomething(list[i]);
        }
    }
  • 解决条件运算:

    synchronized(list) { // 确保调用 size() 后, list 大小不会改变
        int lastIndex = list.size() - 1;
        list.remove(lastIndex);
    }

这样做的弊端是:

做任何操作都要锁住整个容器, 效率低, 容易出错.

迭代器 和 ConcurrentModificationException

Collection进行迭代的标准方法是使用 Iterator, 无论是显式使用还是 通过 JDK 1.5 之后的 for-each 语法. 

在 迭代 的时候, 仍有其他线程在并发修改容器的可能性, 使用迭代器仍不可避免地需要在迭代期间对容器加锁.

迭代器在并发修改的时候, 策略是 及时失败(fail-fast) 的: 当发现迭代器被修改后(如: add 和 remove), 会抛出一个未检查的 ConcurrentModificationException

以 ArrayList 为例子, 其父类 AbstractList 内部有一个字段名为 modCount 的计数器. 任何改变 List 大小的操作都需要改变 modCount 这个值. 

这个值会被用来在迭代或者时, 检查有没有修改容器, 套路是这样的:

修改时:

    if (modCount != expectedModCount) 
        throw new ConcurrentModificationException();
    }
    // Add or Remove
    // .......
    expectedModCount = modCount;

迭代:

    public E prev/next() {
        if (modCount != expectedModCount) 
            throw new ConcurrentModificationException();
        }
        // Other.....
    }

Note: ConcurrentModificationException 也可以出现单线程的代码中, 比如当在迭代期间调用 remove 方法

隐藏的迭代器

有时候, 一些操作会隐含的调用迭代器, 比如:

  1. 调用 toString() 方法, 尤其是写 log 时, 有 

    log("Set:" + set);

    这样的语句.

  2. hashCode 和 equals 方法, 以下是 HashTable 的 hashCode 和 equals 方法:

    public synchronized boolean equals(Object o) {
        if (o == this)
        return true;
    
        if (!(o instanceof Map))
            return false;
        Map<?,?> t = (Map<?,?>) o;
        if (t.size() != size())
            return false;
    
        try {
            Iterator<Map.Entry<K,V>> i = entrySet().iterator();
            while (i.hasNext()) {
                Map.Entry<K,V> e = i.next();
                K key = e.getKey();
                V value = e.getValue();
                if (value == null) {
                    if (!(t.get(key)==null && t.containsKey(key)))
                        return false;
                } else {
                    if (!value.equals(t.get(key)))
                        return false;
                }
            }
        } catch (ClassCastException unused)   {
            return false;
        } catch (NullPointerException unused) {
            return false;
        }
    
        return true;
    }
    
    public synchronized int hashCode() {
        int h = 0;
        if (count == 0 || loadFactor < 0)
            return h;  // Returns zero
    
        loadFactor = -loadFactor;  // Mark hashCode computation in progress
        Entry<?,?>[] tab = table;
        for (Entry<?,?> entry : tab) {
            while (entry != null) {
                h += entry.hashCode();
                entry = entry.next;
            }
        }
    
        loadFactor = -loadFactor;  // Mark hashCode computation complete
    
        return h;
    }
  3. 另外 containAllremoveAll 和 retainAll 也会产生迭代.

JDK 1.5 之后的容器

JDK 1.5 后, 新增加了:

  • ConcurrentHashMap, 来替代同步的 Map 实现, 增加了 put-if-absent, 替换和条件删除
  • CopyOnWriteArrayList, 是 List 相应的同步实现
  • Queue, 用来临时保存正在等待进一步处理的一系列元素, 实现包括
    • ConcurrentLinkedQueue, 一个传统的 FIFO 队列
    • PriorityQueue, 一个(非并发)居右优先级顺序的队列
  • BlockingQueue, 拓展自 Queue, 增加了可阻塞的插入和获取操作. 
    • 如果队列是空的, 那么获取操作会被阻塞直到有元素存在; 
    • 如果队列是满的, 那么插入操作会被阻塞直到有有元素被取出.

JDK 1.6 后, 新增加了 

  1. Deque 和 BlockingDeque, 分别扩展了 Queue 和 BlockingQueue:

    • Deque 接口, 实现类是 ArrayDeque, 不阻塞
    • BlockingDeque 接口, 实现类是 LinkedBlockingDeque, 阻塞.
  2. ConcurrentSkipListMap 和 ConcurrentSkipListSet, 作为 SortedMap 和 SortedSet 的并发替代品

Note: 从一个空的Queue中取元素, 并不会阻塞, 而是返回 null

ConcurrentHashMap

在 ConcurrentHashMap 之前, HashTable 和 SynchronizedMap 都是通过给整个方法加 synchronized 来达到同步的, 这样限制某一时刻只有一个线程可以访问容器.

ConcurrentHashMap 使用一个更加细化的锁机制, 名叫分离锁. 这个机制允许更深层次的共享访问: 

  • 任意数量的读线程可以并发访问 Map.
  • 读者和写者可以并发访问 Map.
  • 有限数量的写线程可以并发修改 Map.

由于并发环境中, Map 的大小通常是动态的, size 和 isEmpty 返回的只是个估算值(可能返回后接着过期).

支持的复合操作:

  1. put-if-absent
  2. remove-if-equal
  3. replace-if-equal

CopyOnWriteArrayList

写入时复制(COW)容器的线程安全原理:

只要不可边对象被正确发布, 那么访问它将不需要更多的同步.

因此, 每次添加/修改一个元素, 容器内就会新创建一个新的数组, 容器底层的数组会指向这个新数组. 旧数组仍然被使用, 直到没有引用后被 GC 回收.

由于 COW 复制数组有开销, 所以 COW 适用于容器迭代操作远远高于对容器修改的频率.

FAQ: Arrays.copyOf 和 System.arraycopy 区别?

Arrays.copyOf 不仅会复制元素, 还会创建新的数组. System.arrayCopy 拷贝到一个现有数组, Arrays.copyOf 实现中用了 System.arrayCopy;

阻塞队列和生产者-消费者模式

生产者-消费者设计分离了 "识别需要完成的工作" 和 "执行工作". 该模式不会发现一个工作便立即处理, 而是把工作置入一个任务清单中:

  • 生产者不需要知道消费者的身份或者数量, 甚至根本没有消费者.
  • 消费者也不需要知道生产者是谁, 以及是谁给它们安排的工作.
  • 生产者和消费者的关系是相对的, 消费者可以成为下一个任务队列的生产者

最常见的生产者-消费者设计是: 线程池和工作队列的结合

在设计初期就使用阻塞队列建立对资源的管理, 提早做这件事情会比日后再修复容易的多.

Blocking queue 提供了可阻塞的 put 和 take 方法. 常见的实现有:

  1. LinkedBlockedQueue, FIFO, 链表实现, 队列首 take, 队列尾 put.
  2. ArrayBlockingQueue, FIFO, 数组实现, 可以在 putIndex(队列尾) 插入, 从 takeIndex(队列首) 取出.
  3. PriorityBlockingQueue, 根据 Comparator 排序顺序取出
  4. SynchronousQueue, 生产线程直接和消费线程对接, 如果生产线程找不到消费者或反之, 则, put 和 take 会一直阻止. 只有在消费者充足的时候比较适合, 他们总能为下一个任务做好准备.

双端队列和窃取工作

双端队列用来实现 窃取工作(work stealing) 模式. 

在传统的 生产者-消费者 设计中, 所有的消费者只共享一个工作队列.

而在 窃取工作 设计中, 每一个消费者都有一个自己的双端队列. 如果一个消费者完成了自己双端队列中的全部工作, 它可以偷取其他消费者的双端队列的 末尾 任务(其他消费者仍然从队列  取任务). 

因为工作者线程并不会竞争一个共享的任务队列, 所以 窃取工作 模式比传统的 生产者-消费者 设计有更好的伸缩性.

阻塞和可中断的方法

阻塞: 线程被挂起, 状态变为BLOCKEDWAITING 或是 TIMED_WAITING等待直到一个事件发生才能继续进行.

BlockingQueue 的 put 和 take 方法会抛出一个受检查的 InterruptedException, 这个异常说明这是个阻塞方法, 可以被中断来提前结束阻塞.

处理中断的方法:

  • 传递 InterruptedException. 传递给调用者, 可以对其中特定活动进行简洁地清理后, 再抛出.
  • 恢复中断. 当代码是 Runnable的一部分时, 必须捕获 InterruptedException. 并且, 在当前线程中调用 interrupt 重新设置中断状态(抛出异常会清理中断标志位), 这样调用栈中更高层代码可以发现中断已经发生. 

    try {
        processTask(queue.take());
    } catch (InterruptedException e) {
        // 恢复中断状态
        Thread.currentThread().interrupt();
    }

Synchronizer

Synchronizer 是一个对象, 它根据本身的状态调节线程的控制流. 主要类型有:

  1. 信号量(semaphore)
  2. 关卡(barrier)
  3. 闭锁(latch)

他们的特性: 封装状态, 这些状态绝对着线程执行到某一点时是通过还是被迫等待.

闭锁 latch

直到 闭锁 到达 终点状态 之前, 门一直是关闭的, 没有线程能够通过, 在 终点状态 到来的时候, 门开了, 允许所有线程通过. 一旦到了终点状态, 他就 不能 再改变状态了.

用例:

  1. 确保一个计算不会执行, 直到它需要的资源初始化.
  2. 确保一个服务不会开始, 直到它依赖的其他服务都已经开始.
  3. 所有玩家等待就绪, 再开始.

FutureTask

FutureTask 描述了一个抽象的可携带结果的计算. FutureTask的计算通过 Callable 实现.

Callable 等价于一个可携带结果的 RunnableCallable 有三种状态:

  1. 等待
  2. 运行
  3. 完成(包括正常结束, 取消 和 异常)

要获取 FutureTask 的结果, 可以调用 get() 方法. 调用 get() 时, 有两种情况:

  1. 若已经完成, 则直接获取结果
  2. 若还未完成, 则阻塞, 直至任务完成返回结果或者抛出异常.

FutureTask 保证了计算结果将计算线程安全的传递到当前线程. 

假如FutureTask执行的任务有异常抛出, 则异常会被封装在 ExecutionException 里. 以下代码可以从 ExecutionException 中取出异常:

    try {
        futureTask.get();
    } catch (ExecutionException e) {
        Throwable cause = e.getCause(); 
        if (cause instanceOf XXXException) {
            // 自己想要捕获的异常
        } else {
            throw launderThrowable(cause);
        }
    }

    public static RuntimeException launderThrowable(Throwable cause) {
        if (t instanceOf RuntimeException) {
            return (RuntimeException)t;
        } else if (t instanceOf Error) {

        } else {
            throw new IllegalStateException("Not unchecked", t);
        }
    }

信号量 (Semaphore)

计数信号量用来控制能够同时访问某种资源的活动的数量, 或者同时执行某一操作的数量.

使用计数信号量之前需要先构造一个, 构造时可以将许可集(permit)总数传递进去. 在使用计数信号量时, 要先尝试获取(acquire)一个许可, 假如此时有剩余许可则继续执行, 若没有, 则 阻塞. 使用完之后, 要手动释放(release)一个许可. 

用处:

  1. 构造一个定长的池.
  2. 构建有界阻塞容器.

关卡 (CyclicBarrier)

关卡用来阻塞一组线程, 直到 所有线程 达到一个条件. 就像一些家庭成员指定商场的一个集合地点:"我们每个人6:00在麦当劳见, 到了以后不见不散, 之后我们再决定接下来做什么". 

关卡 与 闭锁 的不同:

关卡: 等待的是其他线程, 可以重复被使用 闭锁: 等待的是事件, 只能使用一次

当一个线程到达关卡点时, 调用 awaitawait 会被阻塞, 直到所有线程都到达关卡点.

  • 如果所有线程都到达了关卡点, 关卡就被成功地突破, 所有线程会被释放.
  • 如果对 await 的调用超时, 或者阻塞中的线程被中断, 那么关卡就被认为是 失败 的. 

    • 若某一个线程调用有时限的 await, 那么当这个线程 await 超时, 这个线程会抛出 TimeoutException 异常, 其他调用 barrior.await() 的线程会抛出 BrokenBarrierException;

如果成功地通过关卡, await 为每一个线程返回一个唯一的到达索引号, 可以用来 "选举" 产生一个领导, 在下一次迭代中承担一些特殊工作.

CyclicBarrier 也允许你向构造函数传递一个 关卡行为(Barrier action), 这是一个 Runnable, 当成功通过关卡的时候, 会(在 某一个 子任务线程中) 执行, 但是在阻塞线程被释放之前是不能执行的.

Exchanger

Exchanger 是关卡的另一种形式, 它是一种两步关卡, 在关卡点会交换数据.

以上是关于JDK对容器的支持和限制的主要内容,如果未能解决你的问题,请参考以下文章

jdk11新特性——完全支持Linux容器(包括Docker)

Java 并发编程 - 3

【Docker】限制容器磁盘大小

5.cgroup资源控制

jdk8的加密 jdk11不支持

深入理解Spring的容器内事件发布监听机制