在上个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