The standard hash computation for character sequences in Java relies on a polynomial rolling hash function. The core implementation multiplies the accumulated hash value by a constant factor before adding the next character code.

public static int computeStringHash(char[] data) {
    int result = 0;
    for (char c : data) {
        result = 31 * result + c;
    }
    return result;
}

The selection of 31 as the multiplier is not arbitrary. It balances computational efficiency with hash distribution quality. Multiplication by 31 can be optimized by the JVM into a bitwise shift and subtraction: (i << 5) - i. This avoids expensive CPU multiplication instructions. Furthermore, 31 is an odd prime number. Using an even multiplier would cause information loss during overflow because multiplication by 2 is equivalent to a left shift, discarding the most significant bit. Prime multipliers help minimize patterns in the input data that could lead to clustering.

To evaluate how different constants affect collision rates, a benchmark can be constructed using a large dictionary of English words. The following utility calculates hash values with a configurable factor:

public static int generateHash(String text, int factor) {
    int accumulator = 0;
    for (int idx = 0; idx < text.length(); idx++) {
        accumulator = factor * accumulator + text.charAt(idx);
    }
    return accumulator;
}

Running this function against a dataset of approximately 100,000 unique words yields the following collision metrics across various multipliers:

int[] factors = {2, 3, 5, 7, 17, 31, 32, 33, 39, 41, 199};
for (int f : factors) {
    Set<Integer> uniqueHashes = new HashSet<>();
    for (String word : dictionary) {
        uniqueHashes.add(generateHash(word, f));
    }
    int collisions = dictionary.size() - uniqueHashes.size();
    double collisionRate = (collisions * 100.0) / dictionary.size();
    System.out.printf("Factor: %3d | Collisions: %5d | Rate: %.4f%%%n", f, collisions, collisionRate);
}

Output:

Factor:   2 | Collisions: 60382 | Rate: 58.0730%
Factor:   3 | Collisions: 24300 | Rate: 23.3708%
Factor:   5 | Collisions:  7994 | Rate: 7.6883%
Factor:   7 | Collisions:  3826 | Rate: 3.6797%
Factor:  17 | Collisions:   576 | Rate: 0.5540%
Factor:  31 | Collisions:     2 | Rate: 0.0019%
Factor:  32 | Collisions: 34947 | Rate: 33.6106%
Factor:  33 | Collisions:     1 | Rate: 0.0010%
Factor:  39 | Collisions:     0 | Rate: 0.0000%
Factor:  41 | Collisions:     1 | Rate: 0.0010%
Factor: 199 | Collisions:     0 | Rate: 0.0000%

The data demonstrates that small even numbers and powers of two (like 2 and 32) produce severe collision rates due to bit-shifting behavior and rapid overflow patterns. While larger primes like 39, 41, or 199 achieve near-zero collisions, they increase the likelihood of integer overflow wrapping in unpredictable ways for longer strings and offer diminishing returns relative to computational cost. The constant 31 achieves a near-optimal balance: exceptionally low collision probability while remaining small enough for efficient CPU register operations.

Hash uniformity across memory buckets is equally critical. The following routine maps generated hash codes into 64 discrete segments to visualize distribution density:

public static int[] analyzeDistribution(Collection<String> dataset, int factor) {
    int bucketCount = 64;
    int[] buckets = new int[bucketCount];
    for (String item : dataset) {
        int h = generateHash(item, factor);
        int index = (h ^ (h >>> 16)) & (bucketCount - 1);
        buckets[index]++;
    }
    return buckets;
}

Executing the distribution analysis produces the following bucket occupancy arrays:

Factor 2:  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 103910, 34, 0, 18, 0, 0, 7, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 2, 0, 0, 0, 0]
Factor 7:  [310, 364, 284, 292, 393, 506, 656, 460, 451, 410, 441, 522, 485, 458, 725, 559, 391, 493, 319, 308, 479, 469, 454, 354, 491, 486, 361, 425, 347, 442, 245, 317, 38397, 15253, 286, 371, 869, 1509, 2012, 1049, 1186, 2890, 7992, 6821, 975, 1061, 1467, 1130, 1350, 1200, 482, 291, 319, 301, 241, 245, 324, 239, 260, 272, 433, 317, 266, 471]
Factor 31: [1292, 1065, 1197, 1148, 1217, 978, 1157, 1157, 1203, 1099, 1737, 3011, 2235, 2160, 1612, 2443, 2004, 1941, 3268, 2047, 1792, 1615, 1257, 1316, 1350, 1297, 1234, 1698, 1318, 1137, 1217, 1385, 8237, 8404, 1214, 1205, 1199, 1174, 1092, 1203, 1472, 1047, 1125, 1264, 1317, 1075, 1527, 1231, 1552, 1041, 1201, 1085, 1258, 1153, 1255, 1223, 1289, 1084, 1008, 1440, 1230, 1400, 1107, 1277]
Factor 32: [0, 0, 1607, 1044, 1614, 1559, 1135, 1575, 1664, 2360, 1733, 2642, 1305, 301, 195, 0, 0, 0, 3653, 1745, 3973, 2144, 2987, 1750, 1090, 3674, 2153, 2471, 1390, 391, 579, 0, 6948, 7109, 2489, 2931, 1340, 980, 1016, 2407, 5064, 2291, 3314, 4285, 1138, 351, 658, 0, 0, 0, 2142, 988, 2709, 485, 1919, 587, 547, 2290, 612, 1555, 870, 57, 160, 0]
Factor 199:[1415, 1455, 1617, 1642, 1491, 1418, 1506, 1663, 1694, 1594, 1450, 1428, 1462, 1545, 1693, 1566, 1354, 1413, 1495, 1720, 1648, 1641, 1473, 1386, 1401, 1468, 1548, 1518, 1342, 1409, 1561, 1656, 4110, 1423, 1319, 1327, 1404, 1639, 1579, 1389, 1406, 1452, 1613, 3019, 3373, 3030, 1748, 1471, 1490, 1469, 1457, 1396, 1457, 1644, 1754, 1624, 1503, 1498, 1304, 1507, 1458, 1501, 1486, 1454]

Multipliers like 2 and 32 cause severe clustering, leaving the majority of buckets empty while overloading specific indices. This occurs because powers of two interact poorly with the modulo operations typically used in hash table indexing, effective masking higher-order bits. The factor 31 spreads values uniformly across the address space, ensuring that hash table implementations maintain O(1) lookup performance without degrading into linked-list traversal scenarios. Larger primes like 199 also distribute well but introduce unnecessary arithmetic overhead without meaningful gains in bucket uniformity for standard string lengths.