LittlePaper

@kernel uuid 不是 32 字节，是 128 位 16 字节。

上面说加变量、加毫秒的都属于歪门邪道，uuid 的格式是有标准的。自己改了就不叫 uuid 了，当然你也可以自定义一个 id 格式，只要能解决问题就行。实际上 version 1 的 time based uuid 本身就是网卡地址加时间，并且按照标准时间戳是 100 纳秒级别的（实际实现不一定）。

关于各种类型 UUID，其优缺点，冲突概率的计算，看看维基百科就都清楚了： https://en.wikipedia.org/wiki/Universally_unique_identifier

另外我觉得单纯依赖于随机数除了依赖于随机数生成器的质量，就完全看脸了。500 万概率虽小，2000 万还有人中呢。randomUUID() 重复的情况网上一搜就会发现有人遇到过，如果对唯一性有很高的要求的话还是可以优化一下，很多人提到的 snowflake 也是一个很好的方案。

找个第三方库生成 version 1 的 uuid。java.util.UUID 好像只支持生成 version 3 和 version 4，用随机数的话数据量大，时间长了还是会重的。

试试 sourcegraph，或者自建 opengrok

觉得主要是为了兼容 Windows，用 sd 卡就会有在手机和电脑之间用来拷数据的需求。格式化成 ext4 的话卡插到 WIndows 电脑上默认就不识别。印象中 Android 系统本身就是 ext4，而 exFAT 还是微软的专利技术。

@Infernalzero 这里是原生类型（ boolean ），a 是另外一个独立的变量，当然会死循环。

@seaswalker 谢谢，确实是 JIT 引起的。原来一直以为是可见性的问题，很多文章都这么写，这次想到数组元素的可见性应该是不受 volatile 影响的，没想到结果出乎意外。不过按我的理解与猜测，可见性的问题理论上是存在的，一个线程修改了共享变量的值，另外一个线程不能立即看到，但最终能够看到，例如会定期地根据主内存的内容刷新工作内存，可能依赖于具体实现。其实我之前也发现了不用 volatile 也不一定造成循环无法退出，例如若在循环中有打印语句的话也可以退出，看来只是在这种简单的空循环下，由于编译优化造成了死循环。

看个人阅读量了，其实大部分电子书挺便宜的。建议把想看的书列个书单在 KU 里面搜一下看能覆盖多少，我去年开了一年的会员后面找书的时候才发现好多书不支持，又只好花钱买。。。