使用系统时间作为UUID

时间:2015-07-30 19:34:41

标签: java time uuid

在我的应用程序中,当用户与某人进行交互时,会向另一个人的通知列表添加新通知。现在我不得不将每个通知作为一个id。

这里的问题是,Id只需要在给定用户的通知列表范围内唯一。此外,我不会存储超过150个通知。

现在,既然我无论如何都要节省每个通知的时间(System.currentTimeMillis()),那么重用它作为id也是安全的吗?

同一用户的两个通知似乎不太可能在同一时间生成。例如。多个人同时喜欢他的帖子等。即使他们这样做,我也不认为我的服务器会在同一时间为每个电话服务。

  

修改

一个安全的例子可以是多个人同时喜欢你的Facebook帖子,服务器为每个事件添加一个独特的通知。 (保持用户体验)

3 个答案:

答案 0 :(得分:3)

为什么你还应该使用uuid有几个原因。 首先,因为并发问题的理论是它们总是不可能发生。然而,实践证明它们确实经常发生。

还想象某人试图在您的软件中找到错误。那个人首先会对你只是使用系统时间并假设他正在寻找的错误与并发相关这一事实感到困惑。他可能要花几个小时来调试它。

最后,保存这些位是没有意义的。即使您存储了100万个长值,您也可以使用不到7 MB的空间 - 现在,即使是服务器,它也不会出现在手机上。

因此,添加该值不仅可以提高应用程序的稳健性(和可理解性),还可以确保您不会在thedailywtf.com上结束;)

答案 1 :(得分:2)

时间是计算机中最难处理的事情之一。跨设备的同步是困难的,并且即使对于单个设备,时间也可能不是严格单调的,例如,由于调整正确的时钟漂移。这可能现在可以使用,但是使用时间作为标识符会在大规模使用时给你带来麻烦,因为你必须处理时区等。

我更喜欢使用哈希函数来创建一个标识符。通过相应地选择哈希函数,您可以调整冲突的可能性,如果需要,可以在哈希数据中包含时间。通过散列所有相关数据,您可以确保只有真正的重复和冲突才会产生相同的值。散列的优点是它可以在没有同步的情况下在任何地方创建确定性结果。

第二种选择是随机选择一种,但在这种情况下,你需要一个良好的熵源,而且它通常比散列更昂贵,更难以预测。

当然,如果标识符可以由单个实体选择,则计数器也是一种选择。对于多方,它需要同步,因此不太适合同步组的大。

答案 2 :(得分:0)

uuid的最佳方法是使用UUID类并生成uuid唯一代码。

但是如果你不熟悉它,请尝试使用System.nanoTime()因为它具有纳秒精度而不是System.currentTimeMillis中的毫秒