高效的HPPC java库

HPPC（高性能的原始集合）库专注高性能和高存储效率优化，提供了经典Java集合的高性能实现，支持所有原生类似，包括List、Set 和Map等。

为什么要使用HPPC

• Java集合包在许多方面是完美的，它不能用于JDK1.5中开始引入的原始类型和自动装箱，这减少了运行时的效率（增加内存使用以及垃圾收集器的开销）
• 这个库和Java集合类以及其它集合类有着不同的设计目标，例如每个类的内部都是公开的，可以供程序员按照自己的愿望改进。

为什么不使用其它的原始集合库

• 有几个通过原始类来实现集合的项目，例如： fastutil、PCJ、GNU Trove、Apache Mahout（COLT集合移植）、Apache Primitive Collections。
• 其中有些是LGPL-ED类型的（很多商业公司往往不惜一切代价避免的许可证类型）。上面说到的一些项目不在保留或不再完整；也有一种写紧密封装的代码（内部私有），实现标准的Java API并且争取快速的恢复错误的趋势。虽然这些都是良好的编程习惯，但并不总是可行的（在许多密集型计算中，应用访问集合类内部是很频繁的）。HPPC有一些稍微不同的目标。如果你需要Java集合符合要求，那么可以尝试fastutil，它非常的棒。

HPPC的设想和目标

设想

• 程序员知道自己在做什么，并可能希望直接访问特定集合的类的内部存储（例如，不使用预定义的迭代器）
• 绝大多数情况下程序使用单线程访问。例如，有一个在并发修改的重复验证的小点。
• 使用原始集合的程序在开发期间使用单元测试和回归测试，所以他们在生产系统中的行为不会被严格验证（我们可以假设使用集合类的代码不会违反给出的一组断言）

从上面这些假设建立以下设计思想：

• 在HPPC中数据类型尽可能简单，对终端代码里的任何优化公开其内部存储。
• 参数验证和状态有效性校验可以使用断言。这意味着约束仅仅能够检查请求是否在运行是发出（java1.4版本以上），当程序被测试和验证时，它运行从约束中检查不会有额外的开销。
• 我们试图避免复杂的接口层次，尽管为了更明确而定义了特定的接口。程序员在设计时应该还是会选择合适的数据结构，并且应该知道自己在做什么。
• HPPC为大多数普通任务例如，过滤，迭代以及合并提供了工具，但是这些工具通常比实现低层次的对数据存储的直接访问更昂贵（如果需要的话可以使用）。
• 对数据序列化没有特别的支持。
• 这个实现不是线程安全的，并且不会试图提供快速的并发问题检测。

设计与实现

• 我们希望HPPC类模板可以实现为普通的Java类，以便典型的编程工具可用于开发，测试等。
• 我们希望HPPC类模板可被用作通常的集合类（适用于封装的数值类型或其它对象类型），但同时我们希望特殊的类能够自动转化为一般类型（为了限制内存消耗并且提高效率由于JIT优化）

接口以及与Java集合API的关系

• HPPC并不是严格按照Java集合API来制定的，尽管为了更便捷地使用我们的确尽量让HPPC API接近Java集合API。在很大程度上HPPC中缺少一个特别的是“视图”部分（子列表或具有键或值的集合）。特定的类提供了这些视图（例如ObjectObjectHashMap），但是对大部分来说，提供特殊的方法以接收范围和闭合的过滤器。如果表现仍不尽人意，每一个类的内部可用于直接操作。Java集合类和HPPC类之间的基本关系见下表。

• 相应类型的方法级的API也相似，但差异也是存在的（参考相应类的Java文档）。

下面让我们来看看它的实现方法，HPPC的示例很少，这里引用的是官方示例。

1.新建一个Java项目，记得下载并引入HPPC的jar包以及JUnit库。

2.将示例中的Helpers和HppcExample_001_IteratingOverLists类复制到相应的包下

3.运行单元测试，可以看到由HPPC实现的List类速度的确快了不少，至于其它的，大家也可以一一试验。

 

HPPC（高性能的原始集合）库专注高性能和高存储效率优化，提供了经典Java集合的高性能实现，支持所有原生类似，包括List、Set 和Map等。

为什么要使用HPPC

• Java集合包在许多方面是完美的，它不能用于JDK1.5中开始引入的原始类型和自动装箱，这减少了运行时的效率（增加内存使用以及垃圾收集器的开销）
• 这个库和Java集合类以及其它集合类有着不同的设计目标，例如每个类的内部都是公开的，可以供程序员按照自己的愿望改进。

为什么不使用其它的原始集合库

• 有几个通过原始类来实现集合的项目，例如： fastutil、PCJ、GNU Trove、Apache Mahout（COLT集合移植）、Apache Primitive Collections。
• 其中有些是LGPL-ED类型的（很多商业公司往往不惜一切代价避免的许可证类型）。上面说到的一些项目不在保留或不再完整；也有一种写紧密封装的代码（内部私有），实现标准的Java API并且争取快速的恢复错误的趋势。虽然这些都是良好的编程习惯，但并不总是可行的（在许多密集型计算中，应用访问集合类内部是很频繁的）。HPPC有一些稍微不同的目标。如果你需要Java集合符合要求，那么可以尝试fastutil，它非常的棒。

HPPC的设想和目标

设想

• 程序员知道自己在做什么，并可能希望直接访问特定集合的类的内部存储（例如，不使用预定义的迭代器）
• 绝大多数情况下程序使用单线程访问。例如，有一个在并发修改的重复验证的小点。
• 使用原始集合的程序在开发期间使用单元测试和回归测试，所以他们在生产系统中的行为不会被严格验证（我们可以假设使用集合类的代码不会违反给出的一组断言）

从上面这些假设建立以下设计思想：

• 在HPPC中数据类型尽可能简单，对终端代码里的任何优化公开其内部存储。
• 参数验证和状态有效性校验可以使用断言。这意味着约束仅仅能够检查请求是否在运行是发出（java1.4版本以上），当程序被测试和验证时，它运行从约束中检查不会有额外的开销。
• 我们试图避免复杂的接口层次，尽管为了更明确而定义了特定的接口。程序员在设计时应该还是会选择合适的数据结构，并且应该知道自己在做什么。
• HPPC为大多数普通任务例如，过滤，迭代以及合并提供了工具，但是这些工具通常比实现低层次的对数据存储的直接访问更昂贵（如果需要的话可以使用）。
• 对数据序列化没有特别的支持。
• 这个实现不是线程安全的，并且不会试图提供快速的并发问题检测。

设计与实现

• 我们希望HPPC类模板可以实现为普通的Java类，以便典型的编程工具可用于开发，测试等。
• 我们希望HPPC类模板可被用作通常的集合类（适用于封装的数值类型或其它对象类型），但同时我们希望特殊的类能够自动转化为一般类型（为了限制内存消耗并且提高效率由于JIT优化）

接口以及与Java集合API的关系

• HPPC并不是严格按照Java集合API来制定的，尽管为了更便捷地使用我们的确尽量让HPPC API接近Java集合API。在很大程度上HPPC中缺少一个特别的是“视图”部分（子列表或具有键或值的集合）。特定的类提供了这些视图（例如ObjectObjectHashMap），但是对大部分来说，提供特殊的方法以接收范围和闭合的过滤器。如果表现仍不尽人意，每一个类的内部可用于直接操作。Java集合类和HPPC类之间的基本关系见下表。

• 相应类型的方法级的API也相似，但差异也是存在的（参考相应类的Java文档）。

下面让我们来看看它的实现方法，HPPC的示例很少，这里引用的是官方示例。

1.新建一个Java项目，记得下载并引入HPPC的jar包以及JUnit库。

2.将示例中的Helpers和HppcExample_001_IteratingOverLists类复制到相应的包下

3.运行单元测试，可以看到由HPPC实现的List类速度的确快了不少，至于其它的，大家也可以一一试验。