Tecnicamente, não é 10
zero, se você admitir uma inicialização preguiçosa da matriz de apoio. Vejo:
public boolean add(E e) {
ensureCapacityInternal(size + 1);
elementData[size++] = e;
return true;
}
private void ensureCapacityInternal(int minCapacity) {
if (elementData == DEFAULTCAPACITY_EMPTY_ELEMENTDATA) {
minCapacity = Math.max(DEFAULT_CAPACITY, minCapacity);
}
ensureExplicitCapacity(minCapacity);
}
Onde
/**
* Default initial capacity.
*/
private static final int DEFAULT_CAPACITY = 10;
Você está se referindo apenas ao objeto de array inicial de tamanho zero que é compartilhado entre todos os ArrayList
objetos inicialmente vazios . Ou seja, a capacidade de 10
é garantida preguiçosamente , otimização que está presente também no Java 7.
É certo que o contrato do construtor não é totalmente preciso. Talvez esta seja a fonte de confusão aqui.
fundo
Aqui está um e-mail de Mike Duigou
Publiquei uma versão atualizada do patch vazio de ArrayList e HashMap.
http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/
Esta implementação revisada não introduz novos campos para nenhuma das classes. Para ArrayList, a alocação lenta da matriz de apoio ocorre apenas se a lista for criada no tamanho padrão. De acordo com nossa equipe de análise de desempenho, aproximadamente 85% das instâncias de ArrayList são criadas no tamanho padrão, portanto, essa otimização será válida para a grande maioria dos casos.
Para HashMap, o uso criativo é feito do campo de limite para rastrear o tamanho inicial solicitado até que a matriz de intervalo seja necessária. No lado da leitura, a caixa vazia do mapa é testada com isEmpty (). No tamanho de gravação, uma comparação de (tabela == EMPTY_TABLE) é usada para detectar a necessidade de aumentar a matriz do balde. Em readObject há um pouco mais de trabalho para tentar escolher uma capacidade inicial eficiente.
De: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015585.html