一种快速生成UUID的方式

java8的uuid生成方式比较方便,但是速度不够快
UUID.randomUUID().toString()
我在自己电脑虚拟机上进行测试4core,8G,2.5GHZ虚拟机,开4个线程,每个线程创建100万个uuid,那么4个线程全部完成,统计速度仅有10w+ ops/sec

为什么要更快的生成速度?

最近要给流计算场景中的事件添加分布式唯一编码,如果生成uuid速度太慢,会成为吞吐的瓶颈
uuid实际上是有标准的,具体实现方法也有很多,格式也有很多种,那么我这里跟jdk的uuid格式保持一致
8-4-4-4-12一共36位,每一位是16进制字符

分布式唯一

mac地址+ 时间信息
UUID生成器获取本机的mac地址信息,那么运行在同一台设备上的生成器使用相同的mac地址信息
时间信息则由下面的方式获取

public static long createTime(final long currentTimeMillis) {
        final long timeMillis = currentTimeMillis * 10000L + 122192928000000000L;
        final long currNewLastTime = atomicLastTime.get();
        if (timeMillis > currNewLastTime) {
            atomicLastTime.compareAndSet(currNewLastTime, timeMillis);
        }
        return atomicLastTime.incrementAndGet();
    }

UUID生成办法

public Appendable toAppendable(final Appendable a) {
        Appendable out = a;
        if (out == null) {
            out = new StringBuilder(36);
        }
        try {
            Hex.append(out, (int) (this.time >> 32)).append('-');
            Hex.append(out, (short) (this.time >> 16)).append('-');
            Hex.append(out, (short) this.time).append('-');
            Hex.append(out, (short) (this.clockSeqAndNode >> 48)).append('-');
            Hex.append(out, this.clockSeqAndNode, 12);
        } catch (IOException ex) {
        }
        return out;
    }

时间信息是个long类型,64位,取高32位作为int类型数字作为UUID的第一个8位,取低32位的前后16位分别作为short类型充当UUID后面的2个4位,这时候剩下的一个4位和12位则是跟mac地址有关
clockSeqAndNode |= Hex.parseLong(macAddress)
clockSeqAndNode同样是long类型,那么取高16位作剩下一个4位,最后的12位则通过跳步得到

public static Appendable append(final Appendable a, final long in, final int length) {
        try {
            for (int lim = (length << 2) - 4; lim >= 0; lim -= 4) {
                a.append(DIGITS[(byte) (in >> lim) & 0xF]);
            }
        } catch (IOException ex) {
        }
        return a;
    }

那么根据上面的原理,我们知道同一个设备上面生成的uuid有几个特点,后面的4+12 = 16位是一致的,不变的
前面的8+4+4里面第一个8位短时间内也是不变的,后面2个4位是不同的,并且连续生成的话,数值也是连续的

01e9e106-eee1-f5b0-b4cc-02426648b365
01e9e106-eee1-f5b1-b4cc-02426648b365
01e9e106-eee1-f5b2-b4cc-02426648b365
01e9e106-eee1-f5b3-b4cc-02426648b365
01e9e106-eee1-f5b4-b4cc-02426648b365
01e9e106-eee1-f5b5-b4cc-02426648b365
01e9e106-eee1-f5b6-b4cc-02426648b365
01e9e106-eee1-f5b7-b4cc-02426648b365
01e9e106-eee1-f5b8-b4cc-02426648b365
01e9e106-eee1-f5b9-b4cc-02426648b365

性能

同样的测试办法,生成速度大概230w+ ops/sec,是jdk8 uuid速度的20多倍,完全可以满足我的需求了。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 160,026评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,655评论 1 296
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,726评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,204评论 0 213
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,558评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,731评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,944评论 2 314
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,698评论 0 203
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,438评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,633评论 2 247
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,125评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,444评论 3 255
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,137评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,103评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,888评论 0 197
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,772评论 2 276
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,669评论 2 271