new BitSet(Integer.MAX_VALUE).size()報告負值：
import java.util.BitSet;
public class NegativeBitSetSize {
public static void main(String[] args) {
BitSet a;
a = new BitSet(Integer.MAX_VALUE);
System.out.println(a.size()); // -2147483648
a = new BitSet(Integer.MAX_VALUE - 50);
System.out.println(a.size()); // -2147483648
a = new BitSet(Integer.MAX_VALUE - 62);
System.out.println(a.size()); // -2147483648
a = new BitSet(Integer.MAX_VALUE - 63);
System.out.println(a.size()); // 2147483584
}
}
在測驗系統上：
$ java -version
openjdk version "11.0.14" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14 9-Ubuntu-0ubuntu2.18.04)
OpenJDK 64-Bit Server VM (build 11.0.14 9-Ubuntu-0ubuntu2.18.04, mixed mode, sharing)
我找不到這方面的錯誤報告。這是已知的或記錄在案的嗎？
uj5u.com熱心網友回復：
我懷疑這會被記錄在案。它肯定不會被“修復”，因為沒有不破壞向后兼容性的明智修復可用，而且它遠沒有足夠的相關性來采取如此激烈的步驟。
在引擎蓋下挖掘 - 為什么會發生這種情況？
雖然 API 檔案沒有做出這樣的保證，但它的效果是size()它只是回傳nBits您在構造BitSet實體時傳遞的值......但四舍五入到下一個可以被 64 整除的值：
sysout(new BitSet(1).size()); // 64
sysout(new BitSet(63).size()); // 64
sysout(new BitSet(64).size()); // 64
sysout(new BitSet(65).size()); // 128
sysout(new BitSet(100).size()); // 128
sysout(new BitSet(128).size()); // 128
sysout(new BitSet(129).size()); // 192
這是合乎邏輯的；該實作使用一個值陣列long來存盤這些位（因為這（8 倍！）比使用例如 a 更有效boolean[]，因為每個布林值仍然占用陣列中的一個位元組，并且整個 long 的位都是單獨的多變的）。
規范不保證這一點，但它解釋了為什么會發生這種情況。
然后它還解釋了為什么你會看到你是什么：Integer.MAX_VALUE是 2147483647。四舍五入到最接近的 64 倍數，你得到...... 2147483648。溢位int的- 和Integer.MAX_VALUE 1/ (int) 2147483648L- 都是相同的值：-2147483648。那是在有符號空間中作為負數存在的一個int值，沒有匹配的正數（這也很有意義：某些位序列需要表示既不是正也不是負的 0。按照慣例/按照 2s 補碼的規則，是java如何以位形式表示所有數字，0在“正”空間中（假設它都是0位）。因此它從那里“浸出”一個數字，那個數字是2147483648。
讓我們修復它！
一個簡單的解決方法是讓size()方法回傳 a long，它可以簡單地表示 2147483648，這是正確的答案。不幸的是，這不是向后兼容的。因此，如果有人要求進行這種更改，則極不可能成功。
另一個解決方法是創建第二種方法，使用一些簡單的名稱，例如accurateSize()or之類的，這樣size()它就不會受到干擾，因此保留了向后兼容性，它確實回傳了long。但這會永遠弄臟 API，因為除了您可以要求的最大 63 數字之外，對于所有情況都無關緊要的細節。（Integer.MAX_VALUE-62 到 Integer.MAX_VALUE 是您可以為 nBits 傳遞的唯一值，這會導致size()回傳負值。回傳的負值將始終為Integer.MIN_VALUE。我懷疑他們會這樣做。
第三個解決方法是撒謊并回傳 Integer.MAX_VALUE ，這不是正確的值（因為在位空間中實際上多 1 位是“可用的”）。鑒于您實際上無法“設定”該位值，因為您無法將 2147483648 傳遞給建構式（因為您必須傳遞 an int，因此該數字不能作為 int 傳遞，如果您嘗試以 -2147483648 結尾，這是負面的并導致建構式拋出，因此不給你一個實體：如果沒有黑客技術，例如使用反射來設定私有欄位，API 不需要處理，你不能制作一個可以實際存盤值的BitSet第 2147483648 位。
This then gets us to what the point of size() is. Is it for telling you the amount of bytes that the BitSet object occupies? If that's the point, it's never been a great way to go about it: The JVM doesn't guarantee that a long[]'s memory size is arrSize*8 bytes (though all JVM impls have that, some low overhead for the array's header structure).
Instead it is perhaps simply to let you know what you can do with it. Even if you call, say, new BitSet(5), you can still set the 6th bit (because why not - it doesn't "cost" anything, I guess that was the intent). You can set all bits from 0 up to the .size() minus 1.
And this gets us to the real answer!
size() is not actually broken. The number returned is entirely correct: That is, in fact, the size. It's merely that when you print it, it 'prints wrong' - because size()'s return value should be interpreted as unsigned. The javadoc of size() explicitly calls out its only point, which is to take that number, and subtract 1: This then tells you the maximum element you can set.
And this works just fine:
BitSet x = new BitSet(Integer.MAX_VALUE);
int maxIndex = x.size() - 1;
System.out.println(maxIndex);
x.set(maxIndex);
The above code works fine. That maxIndex value is 2147483647 (Which is Integer.MAX_VALUE) as expected.
Hence, there's really nothing to do here: The API is fine as is and does what it suggests you use it for accurately. Any API you care to come up with that's 'better' would be backwards incompatible; changing BitSet is not a good idea, adding more methods, java.util.Vector style uglies up the API which is definitely a case of the cure being worse than the disease.
That just leaves adding notes to the docs. If you delve into this level of exotics in docs, you end up with huge documentation that is, again, a cure worse than the disease. The sustainable solution would perhaps be for javadoc to gain a fundamental ability to write esoteric footnotes, which e.g. the javadoc tool can turn into HTML by way of a 'folding' popdown interface element that is folded up by default (i.e. the exotic footnotes are not visible), but can be expanded if you really want to read the details.
Javadoc doesn't have this.
CONCLUSION: One can easily argue the API isn't broken at all; nothing in size() explicitly says that the returned value should be interpreted as a signed int; the only explicit promise is that you can subtract 1 from the result and use that as index, which works fine. At best, you could file a bug report to get the docs updated, except that's not a good idea because it's not (easily) possible to add such esoterics to the documentation. If you do want to go down that path, there's a lot more of this sort of thing in the JDK libraries that aren't documented either.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/452226.html
下一篇：如何處理此斷言除錯失敗