為什么不使用更具大小確定性的類型來實現BitSet？

Question

此處的Java參考指出，布爾類型雖然用信息的“位”表示，但沒有精確定義的大小。 相反，其他類型似乎暗示已定義大小。 例如，一個int是故事末尾的32位。

當我們查看BitSet的規范時，我們可以看到它由布爾值組成。 通過上面的引用，這似乎表明BitSet的“大小”是不確定的-畢竟它是由布爾值組成的。 確實，該文檔指定：

請注意，大小與位集的實現有關，因此它可能隨實現而變化。

所以我的問題是，為什么不使用精確定義的另一個數據類型實現BitSet ？ 例如，如果我們使用一個字節，則可以保證8位的大小，並且不會模糊地認為該大小可能不是我們認為的大小。 的確，必須將大小除以8，但是至少這樣看來，大小更具確定性。

如果我們有一個絕對不能超過某個內存容量的系統，那么擁有一個大小精確的BitSet實現似乎很有用。

Answer 1

我認為方法簽名使用布爾值會在概念上使您陷入困境。

考慮單個位的最簡單方法是關閉/打開，因此布爾值true / false是對其進行建模的便捷方法。 完全另一件事是BitSet內部存儲器，如果您看一下源代碼 ，它將使用一個long數組並使用位掩碼來纏繞各個位。

因此， BitSet的大小與使用的位數密切相關。

Answer 2

BitSet部分要點是它的長度在概念上是無限的-我們可以用它任意操縱許多位。 這不是語義上我們關心的內存消耗，而size只是內存消耗的指示。

Answer 3

一個BitSet不一定由布爾值組成，但是為了易於使用，它會將這些位轉換為布爾值（而不是必須檢查0或1）。

除此之外，該實現很可能會使用某些數據類型，但根據體系結構，這些位可能會使用一堆8位，16位，32位或64位整數（或其他方式）進行存儲。 在大多數系統中，內存約束並不那么困難，因此邏輯大小為5（實際大小為1或8個字節）的位集並不是那么關鍵。

沒錯，您可以僅使用字節來實現位設置，但是可能有理由堅持使用平台的內存對齊方式（可能超過一個字節）。

Answer 4

聽起來好像BitField 需要是實際boolean s的數組，事實並非如此。 例如，您可以在JDK的源代碼中查找當前的實現。 這是一個片段：

/**
 * The internal field corresponding to the serialField "bits".
 */
private long[] words;

因此，在這種情況下，將使用long數組，並通過位掩碼和移位訪問這些位。

Answer 5

與大多數原語不同，Java對象的字節大小沒有很好地定義並且取決於實現，或者由於JIT編譯和JVM內部使用的各種技巧而在應用程序運行時甚至可能改變。 即使在Sun JVM發行版之間， boolean的大小也發生了變化（4個字節對1個字節），並且如果我沒有記錯的話，甚至有一次單個boolean將占用4個字節，而N個booleans數組將占用大約N個時間。 * 1個字節（或者也許是byte類型？）。 無論如何，變量的邏輯大小或其信息容量可能與JVM分配的物理內存完全不同。

BitSet僅在概念上由布爾值組成，並且實現不需要遵循邏輯布局。 確實，大多數實現將對BitSet使用字節數組，並且對每個值僅使用一個位（但是為了使其增長和一些其他內部管理數據，存在一些松弛）。