JPA 实现比较：Hibernate、OpenJPA、Eclipselink

前言

目前处理一些特殊的应用场景会使用到NoSQL、Spark、Redis等特殊的存储类开源应用外，大多数应用场景还是会使用RDBMS做持久化工具，所以我还是决定做一些ORM的测试，一来回应网络上传播的一些不严谨的技术态度（说Hibernate很渣，说只有MyBatis才是救世主等等）；再来也为我的工作做一些理论、实践的铺垫，让我的技术选择变得更有说服力。

测试环境

依托上一篇我翻译的文章《JPA 实现比较：Hibernate、Toplink Essentials、OpenJPA、Eclipselink》的代码和测试环境，做了一些小调整以适应我自己的场景。

1. 修改了一下对象创建，将其直接通过创建而不是克隆的方式，通过计算随机数的方式填充对象属性。

2. 内存对于我来说意义不大，所以抛弃了内存监控的过程，只是记录下读写能力值，简化测试。

3. 消除的开始程序的等待（链接JConsole的时间），直接开始测试用例。

4. 将测试时间变为10分钟，减少我个人的等待。。。可能测试数据会变少。

5. 将查询线程开始间隔做了调整，改为5秒，着重测试数据的读写随机性。

6. 之前文章提到的各个框架版本有一些老旧，对于最新的版本来说并没有说服力，所以我将所有框架都改到了最新稳定版本进行测试。

笔记本：联想 Idea Pad Y470

OS    ：Wnidows 7 Untimate x64

Mem ：4GB 1333 MHz

CPU ：Intel Core I3-2330 2.2GHz

JVM 版本 1.7.0_60-ea

MySQL 5.7.30

框架版本（默认配置）

Hibernate     4.2.1.Final

Eclipselink   2.5.0

OpenJPA      2.2.2

（为啥没有Toplink？你也知道Toplink捐献给Eclipselink了，然后Oracle就不干这东西的维护了，所以。。。）

————————————————————————————————————————————————————————————

结果

 查询、插入的综合平均次数查询的执行次数插入的执行次数Hibernate95900110648975935Eclipselink95516610606585742OpenJPA40787945170813413

结论

从数据上我们可以得出以下结论：

1. Hibernate 和 Eclipselink 的执行性能上，几乎无差别。执行时间为10分钟，几千次的执行次数差距几乎可以忽略，

2. OpenJPA 的写入速度非常优秀，但读取太慢，几乎无法容忍这样的差距，所以在特定场景才需要考虑使用OpenJPA。

3. 相比之下Eclipselink的性能方面的优化来说，目前看来 Hibernate 和 Eclipselink 几乎无差别了，目前看来 Eclipselink 对 JPA 支持要优于 Hibernate。

相比之下，应用场景对JPA的选择就比较重要了，对于多数为读取的应用而言，选择Eclipselink无疑是非常好的选择，对于一些写入场景要求更多的应用就需要考虑OpenJPA了，至于Hibernate则无需考虑没新版本4.0之后对比Eclipselink几乎一点优势都没有。

稍后我会附上复杂查询和插入的对比测试。

----------------------------------------------------------------------------------------------------------------

修正了文章中的语法错误