No ecossistema Java, as interfaces de coleção são ferramentas fundamentais para o gerenciamento de dados. Entre as implementações mais utilizadas para mapeamentos chave-valor, destacam-se HashMap e Hashtable. Embora ambas sirvam ao propósito de armazenar associações, existem diferenças significativas em sua arquitetura, comportamento e uso, que são cruciais para desenvolvedores Java.

Hierarquia de Classes

Uma distinção fundamental reside nas classes ancestrais de cada uma. O HashMap estende a classe abstrata AbstractMap, que fornece uma implementação base da interface Map. Por outro lado, Hashtable herda da classe Dictionary. É importante notar que a classe Dictionary é considerada obsoleta desde o Java 1.2, com a própria documentação recomendando a implementação da interface Map em vez de estendê-la. Ambas as classes, no entanto, implementam as interfaces Map, Cloneable e Serializable.

Disponibilidade de Métodos na API

A interface pública oferecida por essas classes também apresenta variações. A Hashtable, devido à sua herança e design mais antigo, disponibiliza métodos como elements() e contains(). O método elements() retorna uma Enumeration das chaves presentes na tabela, refletindo um padrão de iteração anterior à introdução dos iteradores. O método contains(), por sua vez, verifica a presença de um valor, sendo funcionalmente idêntico a containsValue(), que é um método comum à interface Map.

Suporte a Valores Nulos

Um ponto de contraste significativo é o tratamento de chaves e valores nulos:

• Hashtable: Não permite chaves nem valores nulos. Qualquer tentativa de inserir uma chave nula ou um valor nulo resultará em uma NullPointerException.
• HashMap: Permite uma única chave nula e múltiplos valores nulos. Essa flexibilidade, contudo, introduz uma ambiguidade: se get(chave) retorna null, pode significar que a chave não existe ou que a chave existe e seu valor associado é null. Para verificar a existência de uma chave, deve-se usar containsKey().

Segurança de Threads

A segurança de threads é uma das maiores diferenças entre as duas classes:

• Hashtable: É uma estrutura de dados sincronizada e, portanto, thread-safe. Seus métodos públicos são protegidos por bloqueios intrínsecos (synchronized), o que significa que apenas uma thread pode acessar a tabela por vez. Isso garante a integridade dos dados em ambientes concorrentes, mas acarreta um custo de desempenho em aplicações single-thread ou com baixa concorrência.
• HashMap: Não é thread-safe. Em um ambiente multithreaded sem sincronização externa, pode ocorrer inconsistência de dados, loops infinitos, ou outras falhas imprevisíveis. Embora mais eficiente em cenários single-thread, seu uso em concorrência requer mecanismos de sincronização explícitos ou a utilização de alternativas thread-safe como ConcurrentHashMap, que oferece um desempenho superior ao Hashtable através de estratégias como o bloqueio por segmento (segment locking) ou nós de bloqueio (node locking em versões mais recentes).

Mecanismos de Iteração

Ambas as classes suportam iteração via Iterator. No entanto, a Hashtable, devido à sua idade, também suporta iteração via Enumeration, um mecanismo mais antigo.

Os iteradores de HashMap são do tipo "fail-fast". Isso significa que, se a estrutura do mapa for modificada por qualquer thread (exceto pela própria operação remove() do iterador) enquanto uma iteração está em andamento, o iterador lançará uma ConcurrentModificationException. Esse comportamento é uma heurística projetada para detectar usos incorretos da estrutura, mas não é garantido para todas as situações.

Historicamente, Hashtable não possuía um mecanismo fail-fast. Contudo, a partir do JDK 8, suas implementações de iteradores também incorporam essa característica, utilizando um contador de modificações (modCount). Um exemplo conceitual do mecanismo fail-fast pode ser visto na lógica de avanço do iterador:

interface ElementoIteravel {
    // ...
}

class IteradorVerificador {
    private final int expectativaModificacoes;
    private final int modificacoesAtuais; // Representa o modCount da coleção
    private ElementoIteravel proximoElemento;

    public IteradorVerificador(int modCountInicial, ElementoIteravel elemento) {
        this.expectativaModificacoes = modCountInicial;
        this.modificacoesAtuais = modCountInicial; // Simples para ilustração
        this.proximoElemento = elemento;
    }

    public ElementoIteravel obterProximo() {
        // Em uma implementação real, modificacoesAtuais seria o modCount da coleção
        // e seria acessado no momento da chamada de obterProximo().
        if (modificacoesAtuais != expectativaModificacoes) {
            throw new java.util.ConcurrentModificationException("A coleção foi modificada externamente durante a iteração.");
        }
        ElementoIteravel atual = proximoElemento;
        // Lógica para avançar para o próximo elemento...
        return atual;
    }
}

A variável modCount é incrementada a cada modificação estrutural (adição, remoção, etc.) na coleção. O iterador armazena uma cópia desse modCount ao ser criado (expectedModCount) e verifica se ele coincide com o modCount atual da coleção a cada operação de iteração. Se houver uma discrepância, a exceção é lançada, sinalizando uma modificação concorrente.

Capacidade Inicial e Estratégia de Redimensionamento

Há diferenças na forma como essas coleções são inicializadas e expandem sua capacidade:

• Hashtable: A capacidade inicial padrão é 11. Quando a tabela precisa ser redimensionada, sua capacidade é geralmente duplicada e somada 1 (2n+1). Isso tende a resultar em números primos para a capacidade, o que é preferido para algoritmos de hashing que dependem do operador de módulo para distribuir chaves uniformemente.
• HashMap: A capacidade inicial padrão é 16. Quando um redimensionamento é necessário, sua capacidade é duplicada (2n). A capacidade do HashMap é sempre uma potência de 2. Isso é uma otimização crucial para o cálculo do índice do bucket, pois permite o uso de operações bit a bit (que são mais rápidas) em vez do operador de módulo (%), que é mais lento.

Metodologia de Cálculo de Hash

A forma como o índice de armazenamento de um elemento é determinado é um fator chave para o desempenho:

• Hashtable: Utiliza diretamente o hashCode() do objeto-chave. O índice final é obtido aplicando o operador de módulo à capacidade da tabela (key.hashCode() % capacity). Para um hash mais uniforme com o operador de módulo, o uso de capacidades primas é vantajoso.
• HashMap: Para aproveitar a otimização de usar potências de 2 como capacidade (que permite (capacity - 1) & hash em vez de hash % capacity), o HashMap primeiro aplica uma função de dispersão adicional ao hashCode() da chave. Este processo visa "misturar" os bits do hash original, garantindo que os bits de alta ordem também influenciem o resultado final, mesmo quando a capacidade da tabela é pequena e apenas os bits de baixa ordem do hash são usados no cálculo do índice. Isso ajuda a mitigar o problema de colisões que pode surgir ao usar apenas os bits de baixa ordem de um hash em tabelas de tamanho de potência de 2.

O método de cálculo de hash no HashMap é otimizado para dispersar as chaves de forma mais eficaz, compensando a escolha da capacidade ser uma potência de 2:

static final int calcularHashOtimizado(Object chave) {
    if (chave == null) {
        return 0;
    }
    int codigoHash = chave.hashCode();
    // Aplica um XOR com o hash deslocado para a direita em 16 bits.
    // Isso distribui os bits mais significativos para as posições menos significativas,
    // ajudando a reduzir colisões para tabelas menores (com menor capacidade de bits).
    return codigoHash ^ (codigoHash >>> 16);
}