JDK自带UUID的性能问题

在上个sprint的性能测试中我发现trackingID是我们的top 1性能问题。那为什么生成一个Id会比我们的JSON转换更耗时呢？

要讲清楚这个问题得先从UUID说起。因为正是trackingID包中生成UUID的代码有性能问题。UUID的RFC(4122)是由微软提出的。其中提到了5个变体就是5个不同实现。其中JDK引入的是变体4. 而trackingID包中用的正是JDK的默认实现。

根据RFC 4122, UUID变体4由128位组成，其中第49位到51位表示UUID的变体版本（100），第64位到65位固定为10. 其它位全部随机。随机函数可以是强随机也可以是伪随机。根据wikipedia上的说法，如果每秒产生十亿个UUID,那在100年内有可能会有50%的概率产生一个重复的UUID.

在JDK的实现中用了强随机算法来产生随机数。同时因为这个算法的实现不是线程安全的，所以JDK就在这个方法上加了同步。OK,到这里，问题找到了。就是这个同步导致了在高并发下的性能问题。

关于UUID的其它变体请参考RFC 4122.

要解决这个问题，最简单的办法就是换UUID实现。RFC 4122比较推荐的UUID的变体是变体1. 他是由timestmap + 时钟序列 + 网卡地址组成。目前也有基于MIT的开源实现（http://johannburkard.de/software/uuid/）。 根据我的测试，其性能要比JDK的实现好很多。我看过他的实现，他其中也用到了一个同步，如果想性能更好点。完全可以用原子变量来代替这个同步。那他的性能就会更好。

那回过头来再看一下我们的需求&#x