该文档将方法描述为:
返回的数组中的元素没有排序,也没有任何特定的顺序
但是我不确定这是否意味着每次应用程序调用例程时顺序都不一致。
我正在寻找一种为找到的每个字段配对唯一 ID 的方法——但它还需要与下次运行应用程序时保持一致,即不断生成相同的 ID。
我只想遍历找到的每个字段,并为每个迭代的元素增加一个计数器。然后将特定元素的 ID 分配给计数器等于的任何值,尽管如果字段没有以一致的顺序返回,这些“id”是不一致的。
该文档将方法描述为:
返回的数组中的元素没有排序,也没有任何特定的顺序
但是我不确定这是否意味着每次应用程序调用例程时顺序都不一致。
我正在寻找一种为找到的每个字段配对唯一 ID 的方法——但它还需要与下次运行应用程序时保持一致,即不断生成相同的 ID。
我只想遍历找到的每个字段,并为每个迭代的元素增加一个计数器。然后将特定元素的 ID 分配给计数器等于的任何值,尽管如果字段没有以一致的顺序返回,这些“id”是不一致的。
订单不需要在运行中保持稳定。但是,该字段的hashCode()
值被定义为稳定的(记录为始终为field.getDeclaringClass().getName().hashCode() ^ field.getName().hashCode()
),因此您可以将其用作您的 ID,但要了解哈希码不能保证是唯一的。
或者,您可以getDeclaredFields()
使用适合您的任何排序标准对自己返回的结果进行排序。
但是我不确定这是否意味着每次应用程序调用例程时顺序都不一致。
它不保证它会随着时间的推移保持一致。但它可能会随着时间的推移保持一致。
对于不同的 JVM 版本或供应商,行为可能会有所不同。它可能会受到意想不到的事情的影响......比如类卸载/重新加载,或 JIT 重新编译。
简而言之,即使您的方案看起来有效,它也很容易变得脆弱。依赖无证行为是不明智的。
这也取决于您所说的“随着时间的推移”。如果您的意思是在应用程序的一次运行中“随着时间的推移”,那么与您考虑应用程序的不同运行相比,(IMO)更有可能顺序是一致的。
最后,谨防使用hashcode()
给您下订单。哈希码可能会发生冲突,如果发生冲突,您的排序将不明确。碰撞的概率很小但不为零,如果您的用例与安全相关,那么了解算法的人制造碰撞并不难。