Técnicamente, no es 10
cero, si admite una inicialización perezosa de la matriz de respaldo. Ver:
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);
}
dónde
/**
* Default initial capacity.
*/
private static final int DEFAULT_CAPACITY = 10;
A lo que se refiere es solo al objeto de matriz inicial de tamaño cero que se comparte entre todos los ArrayList
objetos inicialmente vacíos . Es decir, la capacidad de 10
está garantizada de forma perezosa , una optimización que está presente también en Java 7.
Es cierto que el contrato de constructor no es del todo exacto. Quizás esta sea la fuente de confusión aquí.
Antecedentes
Aquí hay un correo electrónico de Mike Duigou
He publicado una versión actualizada del parche ArrayList y HashMap vacío.
http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/
Esta implementación revisada no introduce nuevos campos en ninguna de las clases. Para ArrayList, la asignación diferida de la matriz de respaldo ocurre solo si la lista se crea con el tamaño predeterminado. Según nuestro equipo de análisis de rendimiento, aproximadamente el 85% de las instancias de ArrayList se crean con el tamaño predeterminado, por lo que esta optimización será válida para una gran mayoría de casos.
Para HashMap, se hace un uso creativo del campo de umbral para rastrear el tamaño inicial solicitado hasta que se necesita la matriz de cubos. En el lado de lectura, el caso del mapa vacío se prueba con isEmpty (). En el tamaño de escritura, se utiliza una comparación de (tabla == EMPTY_TABLE) para detectar la necesidad de inflar la matriz de cubos. En readObject hay un poco más de trabajo para intentar elegir una capacidad inicial eficiente.
De: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015585.html