标签：
它是在不影响性能情况下，通用性最强的 JPA 主键生成器。这种方法生成主键的策略可以适用于任何数据库，不必担心不同数据库不兼容造成的问题。
Hibernate 从 3.2.3 之后引入了两个新的主键生成器 TableGenerator 和 SequenceStyleGenerator。为了保持与旧版本的兼容，这两个新主键生成器在默认情况下不会被启用，而不启用新 TableGenerator 的 Hibernate 在提供 JPA 的 @TableGenerator 注解时会有 Bug。
这个bug是什么呢？我们将上一节中的Customer.java的getId方法做如下下 List_1 的修改：
@TableGenerator(name="ID_GENERATOR", table="t_id_generator", pkColumnName="PK_NAME", pkColumnValue="seed_t_customer_id", valueColumnName="PK_VALUE", allocationSize=20, initialValue=10 ) @GeneratedValue(strategy=GenerationType.TABLE, generator="ID_GENERATOR") @Id public Integer getId() { return id; }
上面的@TableGenerator配置指定了initialValue=10，指定了主键生成列的初始值为10，这在 @TableGenerator 的 API 文档中写得很清楚。现在 initialValue 值设置为 10, 那么在单元测试中用 JPA 添加新的 Customer 记录时，新记录的主键会从 11 开始。但是，实际上保存到数据库中的主键值确实1 ！！！
也就是说，在@TableGenerator中配置的initialValue根本不起作用！！！
这实在令人困惑。其实问题出在程序所用的 JPA 提供者（Hibernate）上面。如果改用其他 JPA 提供者，估计不会出现上面的问题（未验证）。Hibernate 之所以会出现这种情况，并非是不尊重标准，而有它自身的原因。现在，为了把问题讲清楚， 有必要先谈谈 JPA 主键生成器选型的问题，了解一下 @TableGenerator 在 JPA 中的特殊地位。
JPA 提供了四种主键生成器，参看表 1：
一般来说，支持 IDENTITY 的数据库，如 MySQL、SQL Server、DB2 等，AUTO 的效果与 IDENTITY 相同。IDENTITY 主键生成器最大的特点是：在表中插入记录以后主键才会生成。这意味着，实体对象只有在保存到数据库以后，才能得到主键值。用 EntityManager 的 persist 方法来保存实体时必须在数据库中插入纪录，这种主键生成机制大大限制了 JPA 提供者优化性能的可能性。在 Hibernate 中通过设置 FlushMode 为 MANUAL，可以将记录的插入延迟到长事务提交时再执行，从而减少对数据库的访问频率。实施这种系统性能提升方案的前提就是不能使用 IDENTITY 主键生成器。
SEQUENCE 主键生成器主要用在 PostgreSQL、Oracle 等自带 Sequence 对象的数据库管理系统中，它每次从数据库 Sequence 对象中取出一段数值分配给新生成的实体对象，实体对象在写入数据库之前就会分配到相应的主键。
上面的分析中，我们把现实世界中的关系数据库分成了两大类：一是支持 IDENTITY 的数据库，二是支持 SEQUENCE 的数据库。对支持 IDENTITY 的数据库来说，使用 JPA 时变得有点麻烦：出于性能考虑，它们在选用主键生成策略时应当避免使用 IDENTITY 和 AUTO，同时，他们不支持 SEQUENCE。看起来，四个主键生成器里面排除了三个，剩下唯一的选择就是 TABLE。由此可见，TABLE 主键生成机制在 JPA 中地位特殊。它是在不影响性能情况下，通用性最强的 JPA 主键生成器。
JPA 的 @TableGenerator 只是通用的注解，具体的功能要由 JPA 提供者来实现。Hibernate 中实现该注解的类有两个：
一是原有的 TableGenerator，类名为 org.hibernate.id.TableGenerator，这是默认的 TableGenerator。
二是新 TableGenerator，指的是 org.hibernate.id.enhanced.TableGenerator。
当用 Hibernate 来提供 JPA 时，需要通过配置参数指定使用何种 TableGenerator 来提供相应功能。
在 4.3 版本的 Hibernate Reference Manual 关于配置参数的章节中（网址可从参考资源中找到）可以找到如下说明：
我们建议所有使用 @GeneratedValue 的新工程都配置 hibernate.id.new_generator_mappings=true 。因为新的生成器更加高效，也更符合 JPA2 的规范。不过，要是已经使用了 table 或 sequence 生成器，新生成器与之不相兼容。
综合这些资源，可以得到如下结论（重要）：
现在回到上面的问题，要解决这个问题只需在 persistence.xml 文件中添加如下一行配置即可List_2：
<!-- Setting is relevant when using @GeneratedValue. It indicates whether or not the new
IdentifierGenerator implementations are used for javax.persistence.GenerationType.AUTO,
javax.persistence.GenerationType.TABLE and javax.persistence.GenerationType.SEQUENCE. Default to false to keep backward compatibility. --> <property name="hibernate.id.new_generator_mappings" value="true"/>
Customer.java的代码只修改了getId方法的注解：
1 package com.magicode.jpa.helloworld; 2 3 import java.util.Date; 4 5 import javax.persistence.Column; 6 import javax.persistence.Entity; 7 import javax.persistence.GeneratedValue; 8 import javax.persistence.GenerationType; 9 import javax.persistence.Id; 10 import javax.persistence.Table; 11 import javax.persistence.TableGenerator; 12 //import javax.persistence.TableGenerator; 13 import javax.persistence.Temporal; 14 import javax.persistence.TemporalType; 15 import javax.persistence.Transient; 16 17 /** 18 * @Entity 用于注明该类是一个实体类 19 * @Table(name="t_customer") 表明该实体类映射到数据库的 t_customer 表 20 */ 21 @Table(name="t_customer") 22 @Entity 23 public class Customer { 24 25 private Integer id; 26 private String lastName; 27 28 private String email; 29 private int age; 30 31 private Date birthday; 32 33 private Date createdTime; 34 35 /** 36 * @TableGenerator 标签的属性解释： 37 * 38 * ①、allocationSize 属性需要赋一个整数值。表示bulk增加的幅度。其默认值为50。 39 * ②、table 属性用于指定生成seed_id的数据表的表名。这里指定为t_id_generator 40 * 41 * 其基本思想就是：从table指定的表中读取一个int值，记为seed_id。然后结合allocationSize得到此次持久化数据 42 * 的初始id号。 43 * 44 * 我们知道，要从数据库中确定一个值，则必须确定其“行”和“列”。JPA自动产生的t_id_generator只有两列。当然，如果该表 45 * 为n个表产生id，则会在t_id_generator表中保存“n行2列”。 46 * 那么，如何从数据表t_id_generator中确定出seed_id用于为Customer实体计算id呢？？JPA会依据Customer实体的 47 * @TableGenerator 属性值来依据下面的规则的到seed_id： 48 * ③、valueColumnName 属性指定了seed_id的列名。valueColumnName="PK_VALUE"也就是指定了 49 * seed_id位于PK_VALUE列中。同时，规定了这一列必须是数值型（int,long等）。 50 * 剩下的任务就是如何从n行中确定出是哪一行？？ 51 * ④、pkColumnName="PK_NAME",pkColumnValue="seed_t_customer_id" 两个一起来确定具体的行： 52 * 在PK_NAME列中，值为seed_t_customer_id的那一行。 53 * ⑤、由上面③和④中确定出来的“行”和“列”就可以得到一个int型的整数值。这个值就是seed_id。 54 * 55 * 注意：我们的数据库中可以没有t_id_generator这张表，JPA会自动帮助我们完成该表的创建工作。自动创建的表只有两列： 56 * PK_NAME(VARCHAR)和PK_VALUE(int)。同时会自动添加一条记录(seed_t_customer_id, 10) 57 */ 58 @TableGenerator(name="ID_GENERATOR", 59 table="t_id_generator", 60 pkColumnName="PK_NAME", 61 pkColumnValue="seed_t_customer_id", 62 valueColumnName="PK_VALUE", 63 allocationSize=20, 64 initialValue=10 65 ) 66 @GeneratedValue(strategy=GenerationType.TABLE, generator="ID_GENERATOR") 67 @Id 68 public Integer getId() { 69 return id; 70 } 71 72 /** 73 * @Column 指明lastName属性映射到表的 LAST_NAME 列中 74 * 同时还可以指定其长度、能否为null等数据限定条件 75 */ 76 @Column(name="LAST_NAME", length=50, nullable=false) 77 public String getLastName() { 78 return lastName; 79 } 80 81 /** 82 * 利用 @Temporal 来限定birthday为DATE型 83 */ 84 @Column(name="birthday") 85 @Temporal(TemporalType.DATE) 86 public Date getBirthday() { 87 return birthday; 88 } 89 90 /* 91 * 通过 @Column 的 columnDefinition 属性将CREATED_TIME列 92 * 映射为“DATE”类型 93 */ 94 @Column(name="CREATED_TIME", columnDefinition="DATE") 95 public Date getCreatedTime() { 96 return createdTime; 97 } 98 99 /* 100 * 通过 @Column 的 columnDefinition 属性将email列 101 * 映射为“TEXT”类型 102 */ 103 @Column(columnDefinition="TEXT") 104 public String getEmail() { 105 return email; 106 } 107 108 /* 109 * 工具方法，不需要映射为数据表的一列 110 */ 111 @Transient 112 public String getInfo(){ 113 return "lastName: " + lastName + " email: " + email; 114 } 115 116 public int getAge() { 117 return age; 118 } 119 120 public void setId(Integer id) { 121 this.id = id; 122 } 123 124 public void setLastName(String lastName) { 125 this.lastName = lastName; 126 } 127 128 public void setEmail(String email) { 129 this.email = email; 130 } 131 132 public void setAge(int age) { 133 this.age = age; 134 } 135 136 public void setBirthday(Date birthday) { 137 this.birthday = birthday; 138 } 139 140 public void setCreatedTime(Date createdTime) { 141 this.createdTime = createdTime; 142 } 143 144 }
main方法如下，每次只需会连续保存两条记录。代码如下：
1 package com.magicode.jpa.helloworld; 2 3 import java.util.Date; 4 5 import javax.persistence.EntityManager; 6 import javax.persistence.EntityManagerFactory; 7 import javax.persistence.EntityTransaction; 8 import javax.persistence.Persistence; 9 10 public class Main { 11 12 public static void main(String[] args) { 13 14 /* 15 * 1、获取EntityManagerFactory实例 16 * 利用Persistence类的静态方法，结合persistence.xml中 17 * persistence-unit标签的name属性值得到 18 */ 19 EntityManagerFactory emf = 20 Persistence.createEntityManagerFactory("jpa-1"); 21 22 // 2、获取EntityManager实例 23 EntityManager em = emf.createEntityManager(); 24 25 // 3、开启事物 26 EntityTransaction transaction = em.getTransaction(); 27 transaction.begin(); 28 29 // 4、调用EntityManager的persist方法完成持久化过程 30 //保存第1条记录 31 Customer customer = new Customer(); 32 customer.setAge(9); 33 customer.setEmail("Tom@163.com"); 34 customer.setLastName("Tom"); 35 customer.setBirthday(new Date()); 36 customer.setCreatedTime(new Date()); 37 em.persist(customer); 38 39 //保存第2条记录 40 customer = new Customer(); 41 customer.setAge(10); 42 customer.setEmail("Jerry@163.com"); 43 customer.setLastName("Jerry"); 44 customer.setBirthday(new Date()); 45 customer.setCreatedTime(new Date()); 46 em.persist(customer); 47 48 // 5、提交事物 49 transaction.commit(); 50 // 6、关闭EntityManager 51 em.close(); 52 // 7、关闭EntityManagerFactory 53 emf.close(); 54 55 } 56 }
现在看执行效果，会发现一个问题。
执行第一次以后两个数据表的状态如下：
从Figure_1我们似乎能看出某些地方和我们最初想的不一样：@TableGenerator中指定了allocationSize=20，那么不应该是第一条记录为11，第二条记录为11+20=31才对吗？现在为什么是12呢？？如果说这里的12是正确的，那么allocationSize=20的作用在哪里体现呢？？还有一个就是figure2中的PK_VALUE的值为什么为51，有什么讲究吗？？
带着上面的这些疑问我们在第一次运行的基础之上将main方法运行第二次得到结果如下：
这一次有意思了！！我们从 Figure_3 中看到第二次运行中持久化的第一条记录的id为11+20=31，这么说来allocationSize=20的作用是在这里体现的不成？？ Figure_3 难道是在告诉我们，allocationSize=20的意思是后一次EntityManager生命周期会在上一次生命周期的第一个id值上增加20，是这样的吗？？还有一个问题就是，Figure_4的值是51+20=71。
上面的问题归根到底是一个问题：@TableGenerator 注解的 allocationSize 属性值的作用是什么？？
上面讲到Hibernate引入了新的TableGenerator实现类。下面先看看有哪些新的用法，然后再讲解关于allocationSize 的问题：
新 TableGenerator 除了实现 JPA TableGenerator 注解的全部功能外，还有其他 JPA 注解没有包含的功能，其配置参数共有 8 项。新 TableGenerator 的 API 文档详细解释了这 8 项参数的含义，但很奇怪的是，Hibernate API 文档中给出的是 Java 常量的名字，在实际使用时还需要通过这些常量名找到对应的字符串，非常不方便。用对应字符串替换常量后，可以得到下面的配置参数表：
在描述各个参数的含义时，表中多次提到了“序列”，在这个表里的意思相当于 sequence，也相当于 segment。这里反映出术语的混乱，如果在 Hibernate 文档中把两个英文单词统一起来，阅读的时候会更加清楚。新 TableGenerator 的 8 个参数可分为两组，前 5 个参数描述的是辅助表的结构，后 3 个参数用于配置主键生成算法。
先来看前 5 个参数，下图是本文示例程序用于主键生成的辅助表，把图中的元素和新 TableGenerator 前 4 个配置参数一一对应起来，它们的含义一目了然。
第 5 个参数 segment_value_length 是用来确定segment_value的长度，即序列名所能使用的最大字符数。从这 5 个参数的含义可以看出，新 TableGenerator 支持在同一个表中放下多个主键生成器，从而避免数据库中为生成主键而创建大量的辅助表。
后面 3 个参数用于描述主键生成算法。第 6 个参数指定初始值。第 7 个参数 increment_size 确定了步长。最关键的是第 8 个参数 optimizer。optimizer 的默认值一栏写的是“依 increment_size 的取值而定”，到底如何确定呢？
为搞清楚这个问题，需要先来了解一下 Hibernate 自带的 Optimizer。
Optimizer 可以翻译成优化器，使用优化器是为了避免每次生成主键时都会访问数据库。从 Hibernate 官方文档中找不到优化器的说明，需要查阅源码，在org.hibernate.id.enhanced.OptimizerFactory 类中可以找到这些优化器的名字及对应的实现类，其中优化器的名字就是新 TableGenerator 中 optimizer 参数中能够使用的值：
Hibernate 自带了 5 种优化器，那么现在就可以加到上一节提到的问题了：默认情况下，新 TableGenerator 会选择哪个优化器呢？
又一次，在 Hibernate 文档中找不到答案，还是要去查阅源码。通过分析 TableGenerator，可以看到 optimizer 的选择策略。具体过程可用下图来描述：
可以看出，hilo 和 legacy-hilo 两种优化器，除非指定，一般不会在实践中出现。接下来很重要的一步就是判断 increment_size 的值，如果 increment_size 不做指定，使用默认的 1，那么最终选择的优化器会是“none”。选中了“none”也就意味着没有任何优化，每次主键的生成都需要访问数据库。这种情况下 TableGenerator 的优势丧失殆尽，如果再用同一张表生成多个实体的主键，构造出来的系统在性能上会是程序员的噩梦。
在 increment_size 值大于 1 的情况下，只有 pooled 和 pooled-lo 两种优化器可供选择，选择条件由布尔型参数 hibernate.id.optimizer.pooled.prefer_lo 确定，该参数默认为 false，这也意味着，大多数情况下选中的优化器会是 pooled。
我们不去讨论 none 和 legacy-hilo，前者不应该使用，后者的名字看上去像是古董。剩下 hilo、pooled 和 pooled-lo 其实是同一种算法，它们的区别在于主键生成辅助表的数值。
在表 3 中提到 hilo 优化器在辅助表中的数值是 bucket 的序号。这里 bucket 可以翻译成“桶”，也可翻译成“块”，其含义就是一段连续可分配的整数，如：1-10，50-100 等。桶的容量即是 increment_size 的值，假定 increment_size 的值为 50，那么桶的序号和每个桶容纳的整数可参看下表：
hilo 优化器把桶的序号放在了数据库辅助表中，pooled-lo 优化器把下一个桶的第一个整数放在数据库辅助表中，而 pooled 优化器则把下下桶的第一个整数放在数据库辅助表中。
从这里就可以解释Figure 1 和 Figure 2 的现象了：Figure 1中的第一个id号是11，在实体类中设置了allocationSize=20， 而Figure 2的数据库辅助表中记录的数据是51。这里的51=11+20+20，也就是下下桶的第一个整数。说明采用了pooled优化器。
举个例子，如果 increment_size=50, 当前某实体分到的主键编号为 60，可以推测出各个优化器及对应的数据库辅助表中的值。如下表所示：
一般来说，pooled-lo 比 pooled 更符合人的习惯，没有设置 hibernate.id.optimizer.pooled.prefer_lo 为 true 时，数据库辅助表的值会出乎人的意料。程序员看到英文单词“pooled”，会和连接池这样的概念联系在一起，这里的池不过是一堆可用于主键分配的整数的“池”，其含义与连接池很相似。
最后，演示一下 Hibernate 新 TableGenerator 的完整功能。新 TableGenerator 的一些功能不在 JPA 中，因此不能使用 JPA 的 @TableGenerator 注解，而是要使用Hibernate 自身的 @GenericGenerator 注解。
@GenericGenerator 注解有个 strategy 参数，用来指定主键生成器的名称或类名，类名是容易找到的，不过写起来太不方便了。生成器的名称却不大好找，翻遍 Hibernate 的 manual，devguide，都无法找到这些生成器的名称，最后还得去看源码。可以在 DefaultIdentifierGeneratorFactory 类中找到新 TableGenerator 的名称应是“enhanced-table”。配置新 TableGenerator 的例子参看 List_5 的代码：
1 @Entity @Table(name="emp4") 2 public class Employee4 { 3 4 @GenericGenerator( name="id_gen", strategy="enhanced-table", 5 parameters = { 6 @Parameter( name = "table_name", value = "enhanced_gen"), 7 @Parameter( name = "value_column_name", value = "next"), 8 @Parameter( name = "segment_column_name",value = "segment_name"), 9 @Parameter( name = "segment_value", value = "emp_seq"), 10 @Parameter( name = "increment_size", value = "10"), 11 @Parameter( name = "optimizer",value = "pooled-lo") 12 }) 13 @GeneratedValue(generator="id_gen") 14 @Id 15 private long id; 16 17 private String firstName; private String lastName; 18 //...... 19 }
不管是 hilo、还是 pooled、或者 pooled-lo，在使用过程中不可避免地会产生空洞。比如当前主键编号分到第 60，接下来重启了应用程序（就是在上面mian运行两次的效果，第二次的第一个id是从31开始，这样中间就有很多的id号没有使用），Hibernate 无法记住上一次分配的数值，于是 61-100 之间的整数可能永远都不会用于主键的分配。很多人会对此不适应，觉得像是丢了什么东西，应用程序也因此不够完美。其实，仔细去分析，这种感觉只能算是人的心理不适，对程序来说，只是需要生成唯一而不重复的数值而已，数据库记录之间的主键编号是否连续根本不影响系统的使用。ORM 程序需要适应这些空洞的存在，计算机的世界里不会因为这些空洞而不够完美。
1、在JPA采用Hibernate实现的情况下，如果在persistence.xml中没有配置<property name="hibernate.id.new_generator_mappings" value="true"/>那么@TableGenerator标签中配置的initialValue属性将不会起任何作用；
2、allocationSize是优化器的一个参数，其默认值为50。如果设定为1，则不会使用优化策略，这样每次持久化一条记录的时候都会读取辅助表的数据，这样做很糟糕；
3、重启应用程序的时候，持久化对象的id会出现空洞现象。但是，没有关系，我们应该接受这种空洞现象；
4、采用TABLE主键生成策略的时候，Hibernate的JPA实现采用了一种优化策略。这样就不需要每次持久化记录的时候都从辅助表中读取种子id，极大的提高了性能；
注：主要参考IBM文档库中的一篇博文 “探索 Hibernate 新 TableGenerator 机制”
博文地址为：http://www.ibm.com/developerworks/cn/java/j-lo-tablegenerator/
另外：IBM文档库 http://www.ibm.com/developerworks/cn/views/java/libraryview.jsp 里面有很多实用性很强的文档
4、JPA table主键生成策略（在JPA中table策略是首推！！！）
标签：
原文地址：http://www.cnblogs.com/lj95801/p/5003580.html
