草稿箱

/*
    * 第一个问题：虽然被包装过的list是线程安全的，但返回的list获得的Iterator仍然是线程不安全的，所以仍然要用Synchronized代码块包裹起来。

至于第二个问题，其实上面的文章链接也有提到, 大意是：与其所有（多线程）要用到该list都加上Synchronized修饰，还不如直接使用安全的collection更聪明。

也就是说，如果不使用Iterator迭代器的话，使用了安全的collection以后，其实我们不需要再用Synchronized代码块修饰了，这样使用上更方便。

反过来说，使用Iterator迭代器的话，似乎也没必要用Collections.synchronizedList的方法来包装了——反正都是必须要使用Synchronized代码块包起来的。

所以总的来说，Collections.synchronizedXX这种做法，适合不需要使用Iterator、对性能要求也不高的情况。
    *
    * */



/*
*
*  这就是所谓的线程安全的类，在多线程中一样会有问题，那这是为什么呢。后来在一篇博文当中看到了说Vector的contains方法和remove方法之前不具备原子性，这点给了提示。
*  我现在认为出错的原因是在get和remove之间并没有在以上环境中做到同步，比方说，一个线程的get（2）操作发生时，正好遇到了remove操作的正在进行，这时get（2）这个操作就会阻塞，
*  等待remove操作释放锁之后去操作。如果这时候remove操作的正好是remov（2）这个操作，等到去get的时候，这个元素已经没有了，get自然就只能是空欢喜一场。
    这里原因找到了，就该说解决办法了，在说解决办法之前，可能还会困惑，说好的线程安全呢，
    我的理解是，线程安全并不代表使用安全，在实际使用时还是需要考虑当前环境中是否会出现问题的。那么问题来了，java提供线程安全的某些类的意义在哪里呢，反正还是会出问题。
    这就显得比较鸡肋了，但是也不能说没有意义，毕竟写程序还是要独立思考的。
    解决办法就比较简单了，在两个线程的run方法里加上synchronized (testVector)，这样就会使得读取、删除线程中只会有一个对testVector进行操作，也就不会有上述情况出现。
    从这个错误来看的话，编程一定要谨慎，使用到的技术一定要深入了解，不能说不出问题，但是在出了问题之后能找出原因并解决，
    如果没有这个把握就不要轻易去使用，尤其在正式项目中，可能会让你欲哭无泪啊！

* */

队列

• deque 双端对列
• queue 阻塞队列 ArrayBlockingQueue ：一个由数组支持的有界队列。LinkedBlockingQueue ：一个由链接节点支持的可选有界队列。DelayQueue ：一个由优先级堆支持的、基于时间的调度队列。
• PriorityQueue 和 ConcurrentLinkedQueue 非阻塞队列