并发容器之CopyOnWriteArrayList

Copy-On-Write简称COW，是一种用于程序设计中的优化策略。其基本思路是，从一开始大家都在共享同一个内容，当某个人想要修改这个内容的时候，才会真正把内容Copy出去形成一个新的内容然后再改，这是一种延时懒惰策略。从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,它们是CopyOnWriteArrayList和CopyOnWriteArraySet。CopyOnWrite容器非常有用，可以在非常多的并发场景中使用到。

什么是CopyOnWrite容器

　　CopyOnWrite容器即写时复制的容器。通俗的理解是当我们往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是我们可以对CopyOnWrite容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以CopyOnWrite容器也是一种读写分离的思想，读和写不同的容器。

CopyOnWriteArrayList的实现原理

　　在使用CopyOnWriteArrayList之前，我们先阅读其源码了解下它是如何实现的。以下代码是向CopyOnWriteArrayList中add方法的实现（向CopyOnWriteArrayList里添加元素），可以发现在添加的时候是需要加锁的，否则多线程写的时候会Copy出N个副本出来。


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

/**

     * Appends the specified element to the end of this list.

     *

     * @param e element to be appended to this list

     * @return <tt>true</tt> (as specified by {@link Collection#add})

     */

    public boolean add(E e) {

    final ReentrantLock lock = this.lock;

    lock.lock();

    try {

        Object[] elements = getArray();

        int len = elements.length;

        Object[] newElements = Arrays.copyOf(elements, len + 1);

        newElements[len] = e;

        setArray(newElements);

        return true;

    } finally {

        lock.unlock();

    }

    }

 　　注：Arrays.copyOf实际用的是System.arraycopy，它是浅拷贝，当然这一点对于CopyOnWriteArrayList的add/remove/size等是没有任何问题的。

      读的时候不需要加锁，如果读的时候有多个线程正在向CopyOnWriteArrayList添加数据，读还是会读到旧的数据，因为写的时候不会锁住旧的CopyOnWriteArrayList。


1

2

3

public E get(int index) {

    return get(getArray(), index);

}

 　　JDK中并没有提供CopyOnWriteMap，我们可以参考CopyOnWriteArrayList来实现一个，基本代码如下：


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

import java.util.Collection;

import java.util.Map;

import java.util.Set;

 

public class CopyOnWriteMap<K, V> implements Map<K, V>, Cloneable {

    private volatile Map<K, V> internalMap;

 

    public CopyOnWriteMap() {

        internalMap = new HashMap<K, V>();

    }

 

    public V put(K key, V value) {

 

        synchronized (this) {

            Map<K, V> newMap = new HashMap<K, V>(internalMap);

            V val = newMap.put(key, value);

            internalMap = newMap;

            return val;

        }

    }

 

    public V get(Object key) {

        return internalMap.get(key);

    }

 

    public void putAll(Map<? extends K, ? extends V> newData) {

        synchronized (this) {

            Map<K, V> newMap = new HashMap<K, V>(internalMap);

            newMap.putAll(newData);

            internalMap = newMap;

        }

    }

}

 　　实现很简单，只要了解了CopyOnWrite机制，我们可以实现各种CopyOnWrite容器，并且在不同的应用场景中使用。

CopyOnWrite的应用场景

　　CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景，假如我们有一个搜索网站，用户在这个网站的搜索框中，输入关键字搜索内容，但是某些关键字不允许被搜索。这些不能被搜索的关键字会被放在一个黑名单当中，黑名单每天晚上更新一次。当用户搜索时，会检查当前关键字在不在黑名单当中，如果在，则提示不能搜索。实现代码如下：


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

package com.ifeve.book;

 

import java.util.Map;

 

import com.ifeve.book.forkjoin.CopyOnWriteMap;

 

/**

 * 黑名单服务

 *

 * @author fangtengfei

 *

 */

public class BlackListServiceImpl {

 

    private static CopyOnWriteMap<String, Boolean> blackListMap = new CopyOnWriteMap<String, Boolean>(

            1000);

 

    public static boolean isBlackList(String id) {

        return blackListMap.get(id) == null ? false : true;

    }

 

    public static void addBlackList(String id) {

        blackListMap.put(id, Boolean.TRUE);

    }

 

    /**

     * 批量添加黑名单

     *

     * @param ids

     */

    public static void addBlackList(Map<String,Boolean> ids) {

        blackListMap.putAll(ids);

    }

 

}

 　　代码很简单，但是使用CopyOnWriteMap需要注意两件事情：

　　1. 减少扩容开销。根据实际需要，初始化CopyOnWriteMap的大小，避免写时CopyOnWriteMap扩容的开销。

　　2. 使用批量添加。因为每次添加，容器每次都会进行复制，所以减少添加次数，可以减少容器的复制次数。如使用上面代码里的addBlackList方法。

CopyOnWrite的缺点

　　CopyOnWrite容器有很多优点，但是同时也存在两个问题，即内存占用问题和数据一致性问题。所以在开发的时候需要注意一下。

　　内存占用问题。因为CopyOnWrite的写时复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存，旧的对象和新写入的对象（注意:在复制的时候只是复制容器里的引用，只是在写的时候会创建新对象添加到新容器里，而旧容器的对象还在使用，所以有两份对象内存）。如果这些对象占用的内存比较大，比如说200M左右，那么再写入100M数据进去，内存就会占用300M，那么这个时候很有可能造成频繁的Yong
GC和Full GC。之前我们系统中使用了一个服务由于每晚使用CopyOnWrite机制更新大对象，造成了每晚15秒的Full
GC，应用响应时间也随之变长。

　　针对内存占用问题，可以通过压缩容器中的元素的方法来减少大对象的内存消耗，比如，如果元素全是10进制的数字，可以考虑把它压缩成36进制或64进制。或者不使用CopyOnWrite容器，而使用其他的并发容器，如ConcurrentHashMap。

　　数据一致性问题。CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。

原文链接:[http://wely.iteye.com/blog/2324816]

时间： 2024-11-09 07:35:48

并发容器之CopyOnWriteArrayList的相关文章

Java并发编程：并发容器之CopyOnWriteArrayList

原文链接: http://ifeve.com/java-copy-on-write/ Copy-On-Write简称COW,是一种用于程序设计中的优化策略.其基本思路是,从一开始大家都在共享同一个内容,当某个人想要修改这个内容的时候,才会真正把内容Copy出去形成一个新的内容然后再改,这是一种延时懒惰策略.从JDK1.5开始Java并发包里提供了两个使用CopyOnWrite机制实现的并发容器,它们是CopyOnWriteArrayList和CopyOnWriteArraySet.CopyOnW

自己动手写Web容器之TomJetty（一） 服务内功经脉

Jetty 是一个开源的servlet容器,它为基于Java的web内容,例如JSP和servlet提供运行环境.Jetty是使用Java语言编写的,它的API以一组JAR包的形式发布.开发人员可以将Jetty容器实例化成一个对象,可以迅速为一些独立运行(stand-alone)的Java应用提供网络和web连接.Tomcat 是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选. Jetty和To

自己动手写Web容器之TomJetty（六） 动态页面引入

在上一节,我们已经完成了TomJetty服务器处理静态页面请求的功能.但是只能处理静态页面请求的服务器并不能满足我们的要求,所以本节我们将为TomJetty服务器完成动态页面请求的处理工作. 所谓动态页面请求,无非就是客户端发送一个请求的url地址或者将一些请求参数提交给某一个url地址,服务器端首先接收到这个url地址并检索其在服务端程序中对应的某个处理类(Servlet),然后在该处理类中执行业务逻辑后产生结果,最终转发给相应的页面在客户端浏览器中显示结果. 一.动态页面请求处理 对于Jav

自己动手写Web容器之TomJetty（五） 包装请求参数

前面我们实现了TomJetty响应无参请求静态页面的功能,但真实情况下,几乎所有请求都得携带参数.不能处理用户参数请求的Web服务器就好比温室里的花朵,始终上不了台面.所以本节我们将为TomJetty加入响应用户参数的功能.此外,前面我们使用的提交请求的方式都是GET方式,但在实际情况下,POST方式使用的更广泛,所以我们也将给TomJetty增加响应POST请求的能力. 一.扩展RequestHeader类 1.在RequestHeader类中新增parameter属性,用于标示请求头中客户请

自己动手写Web容器之TomJetty（四） 静态页面起步

上一节我们实现了将HTTP请求头的内容解析后打印到控制台上,让HTTP请求头的各个组成部分完全暴露在在我们面前.这个功能在IE浏览器的一款叫作HttpWatch的插件中有类似的体现,相信很多读者都用过它,利用HttpWatch查看网页请求和响应的日志信息功能来调试程序.前面讲到我们把HTTP请求头封装在RequestHeader类中,这个类有一个url属性,本节我们将利用它来定位服务器端的静态页面. 一.服务端静态页面 作为一个Web服务器,响应客户端发送的请求是首要任务,怎样设计它才能快速地响

自己动手写Web容器之TomJetty（三） 掀起请求盖头来

前面我们对于实现TomJetty做了一些知识铺垫和复习,息知了HTTP请求的头部的组成元素.目前的TomJetty服务器已经能够成功启动,可是请求一旦过来却又看不懂^_^.所以本文就来解析HTTP请求头,剖析它的各部分.让TomJetty服务器能够明白它的意图. 一.HTTP请求头解析 1.编写一个RequestHeader类,用户封装请求头对象. package cn.lynn.tomjetty; import java.util.HashMap; /** * 封装请求头 * @author

自己动手写Web容器之TomJetty（二） 开启服务器

上一节我们对于实现TomJetty服务器做了一些与Web有关的知识铺垫和回顾.那么从本节正式开始实现TomJetty服务器的"山寨"之旅.要想实现一个服务器,第一步要把服务器建立起来,并且能够正常运行,才能等待来自客户端的请求.考虑到这一点,我们本节就来处理TomJetty服务器的创建和启动工作. 一.服务器建立 1.新建一个名为TomJetty的Java工程. 2.在工程根目录下新建一个tomjetty.config文件,用于提供服务器配置参数. tomjetty.port=9527

大并发服务器之阵痛1：传输响应模式

如果你在淘宝上买过衣服,你会发现,模特的图片一张张的加载起来实在是有点慢.有时候体验简 直很糟糕. 我们来分析下传输生命线: 这是ald.taobao.com 域名下的三次请求,我们发现是按顺序的请求响应,不禁要问,为什么三个请 求不同时进行呢,能不能重叠呢. 现在市面上各类服务器如nginx, apache对HTTP的传输响应目 前都只有一种,即:请求----响应----请求-----响应,我们暂定为传统模式,在传统模式下,每一次 请求都要在上次响应之后才能进行,实际上是拉长了整体的响应时间,

深入Unity 1.x依赖注入容器之二：初始化 Unity

Unity 初始化主要是注册类型映射并指定其生命周期. 在本文中,我们使用了一个接口 IDialer.一个实现了接口的抽象基类 Dialer,二个继承自 Dialer 的具体类 ButtonTypeDialer 和 FigurePlateDialer 类,以及一个使用 Dialer 的 Telephone 类. 生命周期管理 之所以将生命周期的管理放在开始,是因为Unity 会根据在类型的注册时需要指定的生命周期来管理对象的创建和解析. Unity 使用继承自 LifetimeManager 基