为何Java的BitSet内部用long数组，set方法却采用int索引？

Great observation! This is a classic example of how historical context and practical API design shape even the most seemingly odd choices in core Java libraries. Let's start with the details you've highlighted:

BitSet stores its bits internally using a long[] array:

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

But critical methods like set() only accept an int parameter for the bit index:

public void set(int bitIndex) {...}

As you calculated, this creates a massive gap between the theoretical maximum bits the array could support and the ones we can actually access. Here's why this design choice was made:

• Backward Compatibility is Non-Negotiable
  BitSet launched with Java 1.0 in 1996. Back then, JVM heap sizes were capped at 2GB (since 2^31 bytes is ~2GB), which perfectly matches the 2^31-1 bit limit of an int index. Changing the index type to long later would break every existing codebase that relies on int parameters for BitSet operations. Java's core team prioritizes backward compatibility above almost everything else, so this is the single biggest reason the int index remains.

• Practical Usage Seldom Needs More Than 2 Billion Bits
  Think about real-world use cases for BitSet: bloom filters, bitmask flags, sparse set tracking, or bitwise state management. For nearly all of these, a 2-billion-bit limit (which is ~250MB of memory) is more than sufficient. Even today, very few developers ever hit this ceiling. Expanding to long indices would add unnecessary complexity to the API for a feature almost no one would use.

• Even long Indices Are Practically Unusable for Most of Their Range
  You're right that 2GB heaps aren't a barrier anymore, but let's crunch the numbers: a BitSet with 2^63-1 bits would require ~1 exabyte of RAM (since each long holds 64 bits). That's an astronomically large amount of memory—way beyond even the largest enterprise server setups. Even if we had long indices, practically speaking, you couldn't utilize 99.999% of that range anyway.

• Consistency with the Collections Framework
  Almost every other Java collection (like ArrayList, HashMap, LinkedList) uses int for size and indices, as they're designed for collections that fit within the 2^31-1 element limit. BitSet follows this pattern to keep the API consistent, making it easier for developers to learn and integrate with other parts of the language.

内容的提问来源于stack exchange，提问作者No Name QA