[JAVA] Si vous osez comparer Integer avec "==" ...

Que faire si vous souhaitez vérifier si les valeurs entières sont égales? Bien sûr, au lieu d'utiliser "==", vous utilisez la méthode "égal" pour la comparaison. Car, en Java, "==" consiste à vérifier si les instances pointées par la référence sont les mêmes, et à vérifier si les valeurs des instances sont égales en utilisant la méthode "equals". Voilà pourquoi.

Alors que faire si vous osez utiliser "==" pour comparer les valeurs des instances Integer? Voir le code ci-dessous.

Sample.java

public class Sample1 {

	public static void main(String[] args) {

		Integer i1 = 100;
		Integer i2 = 100;

		Integer i3 = 1000;
		Integer i4 = 1000;

		System.out.println("100=100: " + (i1 == i2));
		System.out.println("1000=1000: " + (i3 == i4));
	}
}

Dans ce programme, "100" et "1000" sont comparés à l'aide de "==", mais les résultats sont affichés comme suit.

100=100: true
1000=1000: false

Le résultat était différent selon les chiffres comparés. Pourquoi cela fait-il une différence?

** Comme vous pouvez le voir dans les commentaires, c'est parce qu'IntegerCache a des instances Integer mises en cache. Comme cela n'a rien à voir avec le pool constant, nous allons le corriger. ** **

~~ Pour expliquer cela, nous devons d'abord expliquer l'un des domaines de Java, le "pool constant". ~~

Qu'est-ce qu'une piscine constante?

Les instances de ~~ Integer ne peuvent pas changer leur état interne. C'est immuable. Par conséquent, vous pouvez réutiliser les instances, et il est inutile de créer une instance à chaque fois. Par conséquent, Java VM crée ces instances à l'avance, les stocke dans une certaine zone de la mémoire et les utilise en cas de besoin. Cette zone est appelée "piscine constante". ~~

~~ De même, il y a d'autres choses que Integer qui sont soumises à ce pool constant. Par exemple, une chaîne écrite solidement dans le code source est également une cible pour laquelle une instance est allouée à ce pool de constantes. ~~

Instances à stocker dans le pool de constantes

~~ Comme mentionné ci-dessus, l'instance Integer est préparée à l'avance dans le pool de constantes, et le programme utilise cette instance. Alors pourquoi le code ci-dessus fait-il une différence entre "100" et "1000"? En effet, toutes les instances Integer ne sont pas sur un pool constant. Par défaut, les instances Integer comprises entre -128 et 127 sont ciblées et les instances en dehors de cette plage ne sont pas fournies dans le pool de constantes. ~~

~~ En d'autres termes, dans le code ci-dessus, puisque l'instance obtenue à partir du pool de constantes est utilisée pour "100", l'instance pointée par chaque référence était la même. Cependant, pour "1000", comme l'instance n'était pas préparée dans le pool de constantes, une instance était créée à chaque fois et l'instance pointée par chaque référence était différente et, par conséquent, le résultat de la comparaison avec "==" devenait faux. Cela signifie que c'était le cas. ~~

Résumé

En tant que petite histoire de Java, j'en ai parlé dans la formation des nouveaux arrivants et c'était bien, alors je l'ai écrite.