1。synchronizedList得到的是同步的容器,和非同步的容器到底有什么区别???
因为我看见文档说synchronizedList后还是要synchronized块操作,否则会引起未知错误。
2。“同步的集合包装器以及早期的 Hashtable 和 Vector 类带来的更大的问题是,它们在单个的锁上进行同步。”这句话不是就相当于说明已经进行了synchronized块操作了么?为什么还是需要synchronized块操作?
3。“提高 HashMap 的并发性同时还提供线程安全性的一种方法是废除对整个表使用一个锁的方式,而采用对hash表的每个bucket都使用一个锁的方式”这样实现了还需要synchronized块操作么?
4。“util.concurrent 包中的 ConcurrentHashMap 类(也将出现在JDK 1.5中的 java.util.concurrent 包中)是对 Map 的线程安全的实现,比起 synchronizedMap 来,它提供了好得多的并发性。”怎么看这个问题?

解决方案 »

  1.   

    >>>synchronizedList得到的是同步的容器,和非同步的容器到底有什么区别???
    返回的List是同步的。>>>我看见文档说synchronizedList后还是要synchronized块操作
    只有对这个List顺序访问的时候才需要synchronized。建议阅读英文原版的JDK说明。中文翻译有歧义!>>>这句话不是就相当于说明已经进行了synchronized块操作了么?为什么还是需要synchronized块操作?
    建议阅读英文原版的JDK说明。中文翻译有歧义!>>>3...这样实现了还需要synchronized块操作么?
    不需要>>>4.是对 Map 的线程安全的实现,比起 synchronizedMap 来,它提供了好得多的并发性
    请仔细看看措辞,“实现”,“并发性”。他们的意思是,语义上,他们是等价的,都是线程安全的;但是新的ConcurrentHashMap实现上效率更高,因为它的实现上做了一些优化。
      

  2.   

    >>>我现在是这样理解的。对于任何线程安全的容器来说(不管原来的还是新加的),都不可能实现使用迭代器时候的线程安全,只能保证容器的方法,比如插入和删除的线程安全。是不是这个意思?
    对!>>>后面的新加的,不管原理如何,都是一样的意义:线程安全,不过在执行效率方面有区别。
    基本是这个意思!只是效率不仅体现在“写”上,而且体现在“读”上,甚至很多时候读的效率才是表现整体效率的主要因素
      

  3.   

    跟到实现内部发现实现如下: 
    时机返回的类
    SynchronizedCollection(Collection<E> c) {
                if (c==null)
                    throw new NullPointerException();
        this.c = c;
                mutex = this;
            }而对这个类所作的操作,如add()
    public boolean add(E e) {
        synchronized(mutex) {return c.add(e);}
            }
    也就是说返回的类对于原子操作是加锁的 而非原子还是需要自己去控制 可以参考对java.util.ConcurrentLinkedQueue的操作方式来控制
    如:http://blog.csdn.net/shell_picker/article/details/5540619