Hibernate 中 UUID.HEX的实现机制??

Hibernate主键生成方式 Key Generator
　　主键产生器
　　可选项说明：
　　1) assigned
　　主键由外部程序负责生成，无需Hibernate参与。
　　2) hilo
　　通过hi/lo 算法实现的主键生成机制，需要额外的数据库表保存主键生成历史状态。
　　3) seqhilo
　　与hilo 类似，通过hi/lo 算法实现的主键生成机制，只是主键历史状态保存在Sequence中，适用于支持Sequence的数据库，如Oracle。
　　4) increment
　　主键按数值顺序递增。此方式的实现机制为在当前应用实例中维持一个变量，以保存着当前的最大值，之后每次需要生成主键的时候
　　将此值加1作为主键。
　　这种方式可能产生的问题是：如果当前有多个实例访问同一个数据库，那么由于各个实例各自维护主键状态，不同实例可能生成同样的主键，从而造成主键重复异常。因此，如果同一数据库有多个实例访问，此方式必须避免使用。
　　5) identity
　　采用数据库提供的主键生成机制。如DB2、SQL Server、MySQL中的主键生成机制。
　　6) sequence
　　采用数据库提供的sequence 机制生成主键。如Oralce 中的Sequence。
　　7) native
　　由Hibernate根据底层数据库自行判断采用identity、hilo、sequence其中一种作为主键生成方式。
　　8) uuid.hex
　　由Hibernate基于128 位唯一值产生算法生成16 进制数值（编码后以长度32 的字符串表示）作为主键。
　　9) uuid.string
　　与uuid.hex 类似，只是生成的主键未进行编码（长度16）。在某些数据库中可能出现问题（如PostgreSQL）。
　　10) foreign
　　使用外部表的字段作为主键。
　　一般而言，利用uuid.hex方式生成主键将提供最好的性能和数据库平台适应性。
　　另外由于常用的数据库，如Oracle、DB2、SQLServer、MySql 等，都提供了易用的主键生成机制（Auto-Increase 字段或者Sequence）。我们可以在数据库提供的主键生成机制上，采用generator-class=native的主键生成方式。不过值得注意的是，一些数据库提供的主键生成机制在效率上未必最佳，大量并发insert数据时可能会引起表之间的互锁。
　　数据库提供的主键生成机制，往往是通过在一个内部表中保存当前主键状态（如对于自增型主键而言，此内部表中就维护着当前的最大值和递增量），之后每次插入数据会读取这个最大值，然后加上递增量作为新记录的主键，之后再把这个新的最大值更新回内部表中，这样，一次Insert操作可能导致数据库内部多次表读写操作，同时伴随的还有数据的加锁解锁操作，这对性能产生了较大影响。
　　因此，对于并发Insert要求较高的系统，推荐采用uuid.hex 作为主键生成机制。

在Hibernate中主键的生成方式中有一种是 UUID.HEX方式。
它是Hibernate系统自动生成一个32位长的字符串。
具体的使用方法是： 修改hbm.xml 主键的默认的手动生成方式 <generator class="assigned" /> 为<generator class="uuid.hex" />


如下是两个示例：
<id name="userid" type="java.lang.String">
            <column name="USERID" length="20" />
                      <generator class="uuid.hex" />
</id>


<id name="empno" type="java.lang.String">
            <column name="EMPNO" length="50"/>
        
             <generator class="uuid.hex" ></generator>
</id>


我试着使用这种方法向数据库中插入了几条记录，得到的主键（32位字符串）如下：

402852432955363a012955363c110001
40285243295535a301295535a6980001
40285243295418b801295418bac60001
40285243295535e801295535ea770001


说到32位字符，我很自然的想到了php中的加密运算算法 md5() 。

下面是一些字符md5加密之后的结果：

a6907acf5b337a322193f19b6698c867 (jia)
d3d9446802a44259755d38e6d163e820   (10)
c02d0450cdd75ce7595f5eaeb5f041a3 (7988)
d603f7ff967282ff491e956b21f10a6c  (c02d0450cdd75ce7595f5eaeb5f041a3)
9825f096ee35843407c643a5af383ab0 (d603f7ff967282ff491e956b21f10a6c)


如下是php中测试的代码：

echo "jia"." ========== ".md5(jia)."<br>";
echo "jia"." ========== ".md5("jia")."<br>";
echo "10"." ========== ".md5("10")."<br>";
echo "10"." ========== ".md5(10)."<br>";
echo "7988"." ========== ".md5(7988)."<br>";
echo "c02d0450cdd75ce7595f5eaeb5f041a3"." ==========
".md5(c02d0450cdd75ce7595f5eaeb5f041a3)."<br>";
echo "d603f7ff967282ff491e956b21f10a6c"." ==========
".md5(d603f7ff967282ff491e956b21f10a6c)."<br>";


    UUID.HEX中使用某种算法生成了32位“无意义的”、“原理上不应该重复的字符”。我一直疑心它可能是把一些有序的数字（可以理解为序列）通过md5(或者是类似md5的算法，……应该就是md5,不应该有别的方法了)算法，装换为一些表面上无意义的字符（仔细看一下这些连续插入的主键，他们还是有些规律，至少前面几位还是相同的）。但这些字符作为主键来使用一定是不重复的（这是由数据库中主键的特征决定的）。一些表面上看起来是无意义的字符，同时还要确保他们的唯一性，目前谁能做到这一点？我想也只有md5了…………

查了一下资料： 在Java中是提供了加密算法的
MessageDigest md = MessageDigest.getInstance("MD5"); 
      
但是Java中的md5加密要自己去实现一些方法，对于同一个字符在Java中加密后的结果和在php中md5() 加密后的结果是不同的……
c02d0450cdd75ce7595f5eaeb5f041a3 (7988)  php md5()
2d0450cdd75ce7595f5eaeb5f041a3 （7988）

/*
java.security
类 MessageDigest
java.lang.Object
  java.security.MessageDigestSpi
      java.security.MessageDigest


*/

//package com.tsinghua;

import java.security.*;


public class MD5Tool {


// 主方法

public static void main(String []args){
 
 
    String test="7988";
 
    //创建一个MD5Tool类
    MD5Tool myMd5 =new MD5Tool();
 
    // 调用  MD5Encrypt(String inStr) 方法
    String result=myMd5.MD5Encrypt(test);
 
   // 打印结果
    System.out.println (test+" 加密後的结果是:"+result);
 
}


//该方法将你输入的字符串，通过md5加密，返回一个加密後的字符串

public static String MD5Encrypt(String inStr) { 
 
    MessageDigest md = null; 
    String outStr = null; 
    try {  

     md = MessageDigest.getInstance("MD5");         //可以选中其他的算法如SHA  
     byte[] digest = md.digest(inStr.getBytes());      
     //返回的是byet[]，要转化为String存储比较方便 
     // 调用 bytetoString(byte 方法，返回一个输出结果
     outStr = bytetoString(digest); 
    }
    catch (NoSuchAlgorithmException nsae) {  
     nsae.printStackTrace(); 
    } 
    return outStr;
}

// 

public static String bytetoString(byte[] digest) { 

    String str = ""; 
    String tempStr = ""; 
    for (int i = 1; i < digest.length; i++) {  
     tempStr = (Integer.toHexString(digest[i] & 0xff));  
     if (tempStr.length() == 1) {   
      str = str + "0" + tempStr;  
     }
     else {   
      str = str + tempStr;  
     } 
    } 
    return str.toLowerCase();

}
}

所有的<generator>的Class都是从net.sf.hibernate.id.IdentifierGenerator接口实现得到的，Class属性表示该generator是由哪种方式来生成的。生成方式包括：

increment：生成long, short或者int类型的主键，不能在cluster环境下使用。适用于所有数据库
identity：生成long, short或者int类型的主键。适用于DB2, MySQL, MS SQL Server, Sybase and HypersonicSQL
sequence ：生成long, short或者int类型的主键。适用于DB2, PostgreSQL, Oracle, SAP DB, McKoi，Interbase.
hilo：生成long, short或者int类型的主键。需要提供一个数据库的表来存放生成的主键信息。当采用应用服务器的JTA提供的数据库连接或者用户自定义的数据库连接的时候，不要使用这种主键生成方式。适用于所有数据库
seqhilo：采用给定的数据库的sequence来生成long, short或者int类型的主键。适用于DB2, PostgreSQL, Oracle, SAP DB, McKoi，Interbase.

uuid.hex：采用128位的算法来生成一个32位字符串。最通用的一种方式。适用于所有数据库
uuid.string：同样采用128位的UUID算法。将生成的字符编码位16位。适用于除PostgreSQL.以外的数据库
native：根据具体连接的数据库从identity, sequence或者hilo选择一种来生成主键。适用的数据库根据选择的生成方式确定。
assigned： 交给应用自己给主键赋值。要注意的是赋值必须在调用save()方法之前完成。适用的数据库根据选择的生成方式确定。