使用哪一个collection是最好的？很明显，没有单一的答案可以适合所有的状态。无论如何，以下还是有一些通用的建议。遵循这些建议，我们就可以缩小collection的选择范围。

• 使用collection class 的时候，通过接口来运用。

  如同所有的java程序设计，接口可以隔离开实现的细节。通过使用接口，程序设计师可以轻易地只以修改初始程序代码就将程序重构成使用不同collection的实现。

• 使用没有被同步化过的collection会有小小的性能提升。

  这可能会让许多开发者吃惊---要了解lock取得的性能问题，详见第14章。简单地说，取得lock的性能问题只会发生在竞争的时候。然而，没有被同步化过的collection应该不会竞争lock。如果确实有竞争，那么race condition的问题的可能性会比性能要高。

• 对许多有竞争的算法，考虑改用并发的collection。

  在J2SE5.0中加入的set、hashmap与list collection 有高度的最佳化。如果程序的算法适用其中一种interface，就要考虑J2SE5.0的collection来替换被同步化过的JDK1.2班的collection。并发的collection对多线程的访问有更好的最优化。

• 对生产者/消费者模式的程序，考虑使用queue来作为collection。

  queue最适合生产者/消费者模式是有许多原因的。首先，queue提供对请求的排序，可以防止数据饥饿。第二，queue被高度地最佳化过，有最少的同步、atomic的访问以及在许多情况下甚至可以安全的并行访问。使用这些collection，大量的线程也可以并行地运作 而只有在对queue的访问上有小小的瓶颈。

• 如果可能的话，尽量减少明确同步的使用。iterator与其他需要遍历过整个collection的支持性method可能会比collection提供更多的同步。当有许多线程涉入的时候这可能会是个问题。

• 限制对copy-on-write这类collection使用iterator。

  首先，只在collection的元素数量很少的时候使用这些class，这是由于copy-on-write操作所需要的时间与空间。其次，你的程序不需要collection有最新的信息，iterator只带有创建时间点上的collection的信息而已。

• 考虑使用多个collection。

  虽然某些collection有最小的同步，但在有多个线程涉入的时候这些同步过程还是有问题。考虑使用

多个分段的collecton的算法来代替多个线程使用同一个collection的一般实现方式。

set与map间有少许的差异。

理论上，set与map有好几个方面的差异，但以实现的观点来说，只有一点点的不同。许多set collection就是用map collection实现出来的。这意味着选择实际上并不是选择：存储在set中的元素几乎就是在map中存储的key。