错误JDK-8191002尚不清楚编程错误还是JRE错误 [英] Bug JDK-8191002 unclear if programming error or JRE error
问题描述
关于JDK-8191002中描述的问题，也在 Java密码-PBE中进行了讨论线程安全问题: 我不清楚finalize()方法中Arrays.fill()的用法是否正确或是否有错误.一些答案表明应该使用reachabilityFence，但这是否意味着它是一个错误，或者这意味着该reachabilityFence是围绕VM中的错误的解决方法? 有人可以澄清/评论吗?
Regarding the issue described in JDK-8191002, also discussed in Java Cipher - PBE thread-safety issue : it is unclear to me if the usage of Arrays.fill() in the finalize() method is correct or if it is a bug. Some answers suggest that a reachabilityFence should be used, but does this mean that it was a bug, or does this mean that the reachabilityFence is a workaround around a bug in the VM? Anybody who can clarify/comment?
从 https:/复制/docs.oracle.com/javase/specs/jls/se9/html/jls-12.html#jls-12.6 :此外，该对象字段的未完成预定义读取可能都看不到在该对象的初始化完成之后发生." 这表明JDK-8191002中NewlyAllocatedArrayFilledByOtherInstanceFinalizer的代码是正确的，并且失败是由于JVM引起的.或不?
Copied from https://docs.oracle.com/javase/specs/jls/se9/html/jls-12.html#jls-12.6: "Furthermore, none of the pre-finalization reads of fields of that object may see writes that occur after finalization of that object is initiated." This suggests that the code for NewlyAllocatedArrayFilledByOtherInstanceFinalizer in JDK-8191002 is correct, and that the failure is due to JVM. Or not?
推荐答案
简而言之，这是Java代码中的错误，而不是JVM中的错误.
In short, this is a bug in the Java code, not a bug in the JVM.
此代码模式已在 JDK-8191002 中与
This code pattern has been abstracted in JDK-8191002 with
static class ArrayHolder
{
private byte[] _bytes;
ArrayHolder(final byte[] bytes) { _bytes = bytes.clone(); }
byte[] getBytes() { return _bytes.clone(); }
@Override
protected void finalize() throws Throwable
{
if (_bytes != null)
{
Arrays.fill(_bytes, (byte) 'z');
_bytes = null;
}
super.finalize();
}
}
其中getBytes()确实可能会虚假地返回z填充的数组，而不是返回反映原始内容的数组(从理论上讲，它甚至可能返回部分填充的数组).
where getBytes() may indeed spuriously return z filled arrays instead of an array reflecting the original contents (in theory, it could even return partially filled arrays).
字段的读取"是数组 reference 的读取.克隆数组(或对该数组进行的任何处理)是在之后进行的，因此不会阻止对该字段的所有者进行垃圾收集.
The "reading of a field" is the reading of the array reference. The cloning of the array (or any processing of the array) happens afterwards, hence, doesn’t prevent the owner of the field from being garbage collected.
由于没有任何强制执行线程间内存可见性的操作，因此甚至不需要实际发生读取字段"，线程可以重用先前读取的值(仍在谈论的值)参考)，从而可以更早地收集对象.如果终结器更改了引用，这仍然符合不感知终结器对字段进行写操作的要求.
Since there is no action that enforces inter-thread memory visibility, this "reading of a field" is not even required to actually happen, the thread may reuse a previously read value (still talking of the value of the reference here), allowing an even earlier collection of the object. This still obeys the requirement of not perceiving writes to the field made by the finalizer, if the finalizer changed the reference.
如前所述，这并没有说明阵列的内容，因为阵列不是被垃圾收集的.数组和包含对该数组引用的对象是两个完全不同的对象.
As said, this doesn’t say anything about the array’s contents, as it isn’t the array that has been garbage collected. The array and the object containing a reference to the array are two entirely different objects.
在克隆阵列后将可达性围栏放置在支架上会创建一个新的依赖项，因为在克隆完成之前无法收集到阵列支架.
Placing a reachability fence on holder after the cloning of the array creates a new dependency that wasn’t there in that the array holder can’t get collected before the cloning of the array has been completed.
byte[] getBytes() {
byte[] result = _bytes.clone();
Reference.reachabilityFence(this);
return result;
}
没有它，对对象的最后访问是在clone()调用之前 ，但是如上所述，通过重新使用先前读取的引用，访问可能会得到优化.正如JLS§12.6.1所述:
Without it, the last access to the object is before the invocation of clone(), but as said, that access might get optimized away by reusing a previously read reference. As stated by JLS §12.6.1.:
可以设计程序的优化转换，以将可到达的对象数量减少到少于天真的被认为可到达的对象数量.
Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable.
这篇关于错误JDK-8191002尚不清楚编程错误还是JRE错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
