将ConcurrentLinkedHashMap集成到Guava中意味着什么？
我们在项目中使用来自https://code.google.com/p/concurrentlinkedhashmap/的 ConcurrentLinkedHashMap，我看到了一条说明，它在2010年被集成到了Guava的MapMaker和CacheBuilder中。信息非常简短：
将算法技术集成到MapMaker中将在Google Guava r08中发布，并且很大程度上基于此版本。
这究竟是什么意思？
- concurrentlinkedhashmap项目似乎仍处于活动状态。
- 它只是一次性集成来引导Guava缓存包吗？
- 这两个项目自2010年以来是否独立发展？
- 如果是这样，今天它们之间的主要区别是什么？
这究竟是什么意思？
番石榴是长期替代品，大多数时候你应该使用它。 历史是ConcurrentLinkedHashMap找出算法，Guava包含它，然后专注于添加function。
concurrentlinkedhashmap项目似乎仍处于活动状态。
它一直是一个周末项目，所以主动意味着我有一个划痕痒或响应变更请求。 在CLHM中试验比使用番石榴更容易，所以在我们将它们移植之前，我倾向于certificate那里的想法。 我与番石榴的关系是20％。
它只是一次性集成来引导Guava缓存包吗？
是。 我们首先彻底检查了MapMaker，然后将缓存拆分为专用API。 这是将想法和改进单向迁移到番石榴中。
这两个项目自2010年以来是否独立发展？
两人都致力于他们的目标。 ConcurrentLinkedHashMap背后的动机是弄清楚如何在不采用快捷方式的情况下编写真正的并发缓存。 Guava背后的目标是提供function丰富的库，其中包含一个漂亮的API和可靠的实现，以供广泛使用。
今天它们之间有什么主要区别？
Guava拥有丰富的function，并在Google支持全职团队。 用它！
ConcurrentLinkedHashMap通过装饰而不是分支ConcurrentHashMap具有更高的绝对并发性。 这允许它与ConcurrentHashMapV8一起使用，后者基于新算法。 CLHM不依赖于段锁，这可以提高写入性能并允许维护单个LRU链。 我有一个LIRS政策的实验分支，我希望有一天能完成。
长期的希望是，Doug Lea有一天会写一个受我们工作启发的缓存，并在此过程中教给我们一些东西。
更新（3/15）： Caffeine是Java 8重写的Guava缓存。 它试图提供最好的ConcurrentLinkedHashMap和Guava，使用Java 8进行现代化，并采用自那些以前的项目以来我学到的技术。