我将大量 Java 存储UUID
到HashMap
as 行中,使用UUID.toString()
. 由于数据很大,很快就会抛出OutOfMemoryError
. 现在我正在考虑一种紧凑的方式来表示UUID
,最好是类似long
的,然后我可以很容易地UUID
用这种long
表示重建 。这可能吗?
2 回答
UUID 本质上是一个数字,但它是一个 128 位的数字,是 java long 大小的两倍。您可以使用 BigInteger(这可能并不比将 UUID 存储为字符串更节省空间),或者您可以将 UUID 封装在一个包含两个 long 的对象中——一个用于前 64 位,一个用于后 64 位。
给定 UUID 550e8400-e29b-41d4-a716-446655440000
,您需要创建两个 long ,一个包含 number 0x550e8400e29b41d4
,一个包含 number 0xa716446655440000
。
我将大量 Java 存储
UUID
到HashMap
as 行中,使用UUID.toString()
.
所以你的意思是HashMap<String, MyObject>
?
与. HashMap<UUID, MyObject>
_ HashMap<String, MyObject>
AUUID
占用的空间比实际少String
(两个long
值变为 16 字节,而char[36]
72 字节,这将为您节省近 80% 的空间)。
如果改变这还不够,那么请考虑这些UUID
值在 JVM 中是否重要。如果 ID 只需要对于单个进程是唯一的(您是保存HashMap
到磁盘还是在 Java 进程之间共享它?),那么您可以使用int
,因为 aHashMap
不能比任何情况都大Integer.MAX_VALUE
。因此HashMap<UUID, MyObject>
,您将拥有HashMap<Integer, MyObject>
. 更好的是,Short
如果您将拥有少于 2 16 个对象,则可以使用,从而节省更多空间。但是,如果你得到一个OutOfMemoryError
,我怀疑你可能有超过 65536 个对象。
最后,如果所有其他方法都失败了,请为您的 JVM 分配更多内存,如本问题所示。