文档将该方法描述为：返回的数组中的元素没有排序，也没有任何特定的顺序但是，我不确定这是否意味着应用程序每次调用例程时的顺序都不一致。我正在寻找一种方法来配对一个唯一的ID为每个字段被发现-但它也需要与下一次运行的应用程序是一致的，即不断产生相同的ID。我只想遍历每个找到的字段，并为每个迭代的元素增加一个计数器。然后将特定元素的ID分配给计数器等于的任何值，如果字段没有以一致的顺序返回，则这些“id”不一致。
m1m5dgzv1#
不要求顺序在运行中保持稳定。但是，该字段的hashCode()值被定义为稳定的（它的文档记录始终为field.getDeclaringClass().getName().hashCode() ^ field.getName().hashCode()），因此您可以使用它作为ID，但要理解哈希代码并不保证是唯一的。或者，您可以自己使用适合您的任何排序标准对从getDeclaredFields()返回的结果进行排序。
hashCode()
field.getDeclaringClass().getName().hashCode() ^ field.getName().hashCode()
getDeclaredFields()
m3eecexj2#
但是，我不确定这是否意味着应用程序每次调用例程时的顺序都不一致。它并不保证它会随着时间的推移而保持一致。但随着时间的推移可能会保持一致。而且，对于不同的JVM版本或供应商，行为可能会有所不同。它可能会受到意外的影响...比如类卸载/重载，或者JIT重新编译。简而言之，即使你的计划“看起来”有效，它也可能是脆弱的。依赖无证行为是不明智的。这也取决于你所说的“随着时间的推移”是什么意思。如果您的意思是在应用程序的单次运行中“随着时间的推移”，那么与考虑应用程序的不同运行相比，顺序更有可能是一致的。最后，要注意不要使用hashCode()命令。散列代码可能会发生冲突，如果发生冲突，则排序将不明确。冲突的概率很小，但不是零，如果您的用例与安全相关，那么对于具有算法知识的人来说，制造冲突并不困难。
2条答案
按热度按时间m1m5dgzv1#
不要求顺序在运行中保持稳定。但是，该字段的
hashCode()值被定义为稳定的（它的文档记录始终为field.getDeclaringClass().getName().hashCode() ^ field.getName().hashCode()），因此您可以使用它作为ID，但要理解哈希代码并不保证是唯一的。或者，您可以自己使用适合您的任何排序标准对从
getDeclaredFields()返回的结果进行排序。m3eecexj2#
但是，我不确定这是否意味着应用程序每次调用例程时的顺序都不一致。
它并不保证它会随着时间的推移而保持一致。但随着时间的推移可能会保持一致。
而且，对于不同的JVM版本或供应商，行为可能会有所不同。它可能会受到意外的影响...比如类卸载/重载，或者JIT重新编译。
简而言之，即使你的计划“看起来”有效，它也可能是脆弱的。依赖无证行为是不明智的。
这也取决于你所说的“随着时间的推移”是什么意思。如果您的意思是在应用程序的单次运行中“随着时间的推移”，那么与考虑应用程序的不同运行相比，顺序更有可能是一致的。
最后，要注意不要使用
hashCode()命令。散列代码可能会发生冲突，如果发生冲突，则排序将不明确。冲突的概率很小，但不是零，如果您的用例与安全相关，那么对于具有算法知识的人来说，制造冲突并不困难。