Dans Java 8, pourquoi est la valeur par défaut de la capacité de ArrayList maintenant à zéro?

Que je me souviens, avant Java 8, la valeur par défaut de la capacité de ArrayList était de 10.

Étonnamment, le commentaire sur le défaut (void) constructeur dit encore: Constructs an empty list with an initial capacity of ten.

De ArrayList.java:

/**
 * Shared empty array instance used for default sized empty instances. We
 * distinguish this from EMPTY_ELEMENTDATA to know how much to inflate when
 * first element is added.
 */
private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {};

...

/**
 * Constructs an empty list with an initial capacity of ten.
 */
public ArrayList() {
    this.elementData = DEFAULTCAPACITY_EMPTY_ELEMENTDATA;
}

OriginalL'auteur kevinarpe | 2015-12-13

102

Techniquement, c'est 10, pas de zéro, si vous admettez pour un paresseux initialisation de la sauvegarde de la matrice. Voir:
```
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);
}
```
où
```
/**
 * Default initial capacity.
 */
private static final int DEFAULT_CAPACITY = 10;
```
À quoi vous faites allusion, c'est juste le zéro de la taille initiale de l'objet tableau qui est partagé entre tous les initialement vide ArrayList objets. I. e. la capacité de 10 est garanti paresseusement, une optimisation qui est également présente dans Java 7.

Certes, le constructeur de contrat n'est pas tout à fait exacte. C'est peut-être la source de confusion ici.

Arrière-plan

Voici un E-Mail par Mike Duigou

J'ai publié une version mise à jour du vide ArrayList et HashMap patch.

http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/

Cette mise en œuvre révisé introduit pas de nouveaux champs de la classe. Pour ArrayList le paresseux répartition de la sauvegarde de tableau se produit uniquement si la liste est créée à la taille par défaut. Selon notre analyse de la performance de l'équipe, environ 85% de ArrayList des instances sont créées à la taille par défaut si cette optimisation sera valide pour une écrasante majorité des cas.

Pour table de hachage, créatif est fait usage de la seuil de champ pour suivre la demande initiale de la taille jusqu'à ce que le seau tableau est nécessaire. Sur le côté lecture de la carte vide de cas est testé avec isEmpty(). Sur la taille d'écriture d'une comparaison (tableau == EMPTY_TABLE) est utilisé pour détecter le besoin de gonfler le seau tableau. Dans readObject il y a un peu plus de travail pour essayer de choisir un moyen efficace capacité initiale.

À partir de: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015585.html

Selon bugs.java.com/bugdatabase/view_bug.do?bug_id=7143928 il conduit à réduire l'utilisation du tas et améliorer le temps de réponse (les chiffres pour les deux applications sont affichées)
ArrayList n'a pas vraiment de "rapport" sa capacité, des autres que par le biais de ce Javadoc: il n'y a pas getCapacity() méthode, ou quelque chose comme ça. (Cela dit, quelque chose comme ensureCapacity(7) est un no-op pour un défaut-initialisé ArrayList, donc je suppose que nous sommes vraiment censé agir comme si sa capacité initiale étaient vraiment 10 . . .)
De Nice à creuser. Le défaut de capacité initiale est en effet pas de zéro, mais de 10, avec le cas par défaut étant paresseusement réparti comme un cas spécial. Vous pouvez observer ce si plusieurs fois, vous ajoutez des éléments à un ArrayList créé avec le no-arg constructeur vs passant de zéro à l' int constructeur, et si vous regardez à l'intérieur de la matrice de taille reflectively ou dans un débogueur. Dans le cas par défaut de la matrice de sauts à partir d'une longueur de 0 à 10, puis 15, 22, à la suite de l'1,5 x le taux de croissance. Passant de zéro comme la capacité initiale de croissance de 0 à 1, 2, 3, 4, 6, 9, 13, 19....
Je suis Mike Duigou, auteur de la modification et de la cité email et j'approuve ce message. Stuart dit que la motivation était principalement sur l'économie de l'espace plutôt que sur la performance mais il y a aussi un léger avantage en matière de performances en raison souvent d'éviter la création d'un support de tableau.
non, il a encore sa place en tant que singleton emptyList() toujours consomme moins de mémoire que plusieurs vide ArrayList instances. C'est juste moins important maintenant, et ne sont donc pas nécessaires à tous place, surtout pas dans des endroits avec une probabilité plus élevée d'ajouter des éléments à une date ultérieure. Aussi garder à l'esprit que vous avez parfois voulez est immuable la liste vide et puis emptyList() est le chemin à parcourir.

OriginalL'auteur Lukas Eder

Dans java 8 par défaut de la capacité de ArrayList est de 0 jusqu'à ce que nous ajoutons au moins un objet dans l'objet ArrayList (Vous pouvez l'appeler initialisation différée).

Maintenant la question est de savoir pourquoi ce changement a été fait en JAVA 8?

Réponse est d'économiser de la mémoire de la consommation. Des Millions de tableau liste les objets sont créés en temps réel des applications java. La taille par défaut de 10 objets signifie que nous allouer 10 pointeurs (40 ou 80 octets) pour les sous-jacents au tableau lors de la création et de la remplir avec les valeurs null.
Un tableau vide (rempli avec les valeurs null) occupent beaucoup de mémoire .

Initialisation reporte cette consommation de mémoire jusqu'moment vous allez réellement utiliser le tableau de la liste.

Veuillez voir le code ci-dessous pour obtenir de l'aide.

ArrayList al = new ArrayList();          //Size:  0, Capacity:  0
ArrayList al = new ArrayList(5);         //Size:  0, Capacity:  5
ArrayList al = new ArrayList(new ArrayList(5)); //Size:  0, Capacity:  0
al.add( "shailesh" );                    //Size:  1, Capacity: 10

public static void main( String[] args )
        throws Exception
    {
        ArrayList al = new ArrayList();
        getCapacity( al );
        al.add( "shailesh" );
        getCapacity( al );
    }

    static void getCapacity( ArrayList<?> l )
        throws Exception
    {
        Field dataField = ArrayList.class.getDeclaredField( "elementData" );
        dataField.setAccessible( true );
        System.out.format( "Size: %2d, Capacity: %2d%n", l.size(), ( (Object[]) dataField.get( l ) ).length );
}

Response: - 
Size:  0, Capacity:  0
Size:  1, Capacity: 10

Article Par défaut la capacité de liste de tableaux en Java 8 l'explique dans les détails.

OriginalL'auteur Shailesh Vikram Singh

7

Si la première opération, qui se fait avec une ArrayList est de passer addAll une collection qui a plus de dix éléments, puis tous les efforts mis dans la création d'un premier dix-élément de tableau pour la liste de tableaux du contenu serait jeté par la fenêtre. Chaque fois que quelque chose est ajouté à une liste de tableaux, il est nécessaire de tester si la taille de la liste résultante sera supérieure à la taille de la mémoire de sauvegarde, ce qui permet aux premiers soutiens magasin pour avoir la taille zéro plutôt que dix sera la cause de ce test à l'échec une fois de plus dans la vie d'une liste dont la première opération est une "ajouter", ce qui nécessiterait la création de la dix-élément de tableau, mais ce coût est inférieur au coût de la création d'un dix-point de tableau qui jamais ne finit par s'y habituer.

Cela dit, il aurait été possible d'améliorer encore plus les performances dans certains contextes, si il y avait une surcharge de "addAll" qui précise le nombre d'éléments (le cas échéant) serait susceptible d'être ajouté à la liste après le présent, et qui pourraient l'utiliser pour influencer son comportement allocation. Dans certains cas, le code qui ajoute les derniers éléments d'une liste vous avez une assez bonne idée que la liste n'est jamais va avoir besoin de tout l'espace au-delà. Il existe de nombreuses situations où une liste seront remplis une fois et jamais modifié par la suite. Si le code de point d'sait que la taille définitive de la liste sera de 170 éléments, il dispose de 150 éléments et un magasin de sauvegarde de la taille 160, la culture de la mémoire de sauvegarde de la taille de 320 sera inutile et en le laissant à la taille de 320 ou coupe pour 170 sera moins efficace que de simplement avoir de la prochaine allocation de croître à 170.

Très bons points sur addAll(). C'est encore une autre occasion pour l'amélioration de l'efficacité autour de la première malloc.
Je souhaite Java de la bibliothèque avaient conçu dans certains plus de moyens pour les programmes d'indiquer la façon dont les choses étaient susceptibles d'être utilisées. L'ancien style de la sous-chaîne, par exemple, a été moche pour certains cas d'utilisation, mais excellente pour les autres. S'il y avait eu des fonctions distinctes pour les "sous-chaîne qui est susceptible de survivre à l'original" et "sous-chaîne qui est peu susceptible de survivre à l'original", et le code utilisé la bonne 90% du temps, je pense que ceux-ont largement surperformé l'ancien ou le nouveau de la chaîne de mise en œuvre.

OriginalL'auteur supercat
3

La question est " pourquoi?".

Le profilage de la mémoire des inspections (par exemple (https://www.yourkit.com/docs/java/help/inspections_mem.jsp#sparse_arrays) montre que vide (rempli avec les valeurs null) des tableaux occupent des tonnes de mémoire .

Taille par défaut de 10 objets signifie que nous allouer 10 pointeurs (40 ou 80 octets) pour les sous-jacents au tableau lors de la création et de la remplir avec les valeurs null. Réel des applications java de créer des millions de tableau liste.

L'introduction de cette modification supprime^W reporter cette consommation de mémoire jusqu'moment vous allez réellement utiliser le tableau de la liste.

Merci de corriger "consommer" avec des "déchets". Le lien que vous fournissez ne signifie pas qu'ils commencent à engloutir la mémoire de partout, c'est juste que des tableaux avec des éléments null déchets de la mémoire allouée pour eux, de façon disproportionnée. "Consommer" implique comme par magie ils utilisent de la mémoire au-delà de leur allocation, qui n'est pas le cas.

OriginalL'auteur ya_pulser
0

ArrayList taille par défaut en JAVA 8 est stil 10. La seule modification apportée dans JAVA 8 est que, si un codeur ajoute des éléments à moins de 10 puis le reste de arraylist vide les lieux ne sont pas spécifiées à null. Le dire parce que j'ai moi-même vécu cette situation et eclipse me fait voir dans ce changement de JAVA 8.

Vous pouvez justifier ce changement en regardant la capture d'écran ci-dessous. En lui, vous pouvez voir que ArrayList taille est spécifiée en tant que 10 dans l'Objet[10], mais le nombre d'éléments affichés sont seulement 7. Reste la valeur null éléments ne sont pas affichés ici. Dans JAVA 7 ci-dessous la capture d'écran est la même avec juste un seul changement est que la valeur null éléments sont également affichées pour laquelle le programmeur doit écrire du code pour la gestion des valeurs null si il est une itération complète de la matrice de liste, tandis que dans JAVA 8 ce fardeau est retiré de la tête de codeur/développeur.

Capture d'écran de lien.

OriginalL'auteur tech_lover
0

Après la question ci-dessus j'ai passé par liste de tableaux Document de Java 8. J'ai trouvé la taille par défaut est de 10 seulement.

OriginalL'auteur Rahul Maurya

Vous devez vous connecter pour publier un commentaire.

Arrière-plan