La colonne
Tutoriel de base Java présente les bugs causés par i++.
Bonjour à tous, en tant que rédacteur et réparateur de bugs quotidien, je vais vous présenter aujourd'hui un accident qui vient d'être corrigé il y a quelques jours. Je dois admettre qu'il y a toujours tellement de bugs où que je sois.
Le début de l'histoire s'est produit il y a quelques jours. Il y avait une fonction d'exportation qui n'était pas très utilisée et qui a été signalée par les utilisateurs, quelles que soient les conditions, il n'y a qu'une seule donnée exportée, mais en fait il y a beaucoup de données interrogées en fonction des conditions, et beaucoup de données sont également interrogées sur la page. (Ce problème a été résolu, de sorte que les journaux Kibana à ce moment-là ne peuvent plus être trouvés.) J'ai donc abandonné mon travail et j'ai commencé à examiner ce problème.
D'après la description du problème, celui-ci ne peut survenir que dans les situations suivantes :
Digression
En écrivant ceci, j'ai soudain pensé à une question d'entretien classique, l'analyse de la cause de la perte de message MQ. Hahaha, en fait, c'est grossièrement analysé sous plusieurs angles. (J'ai l'occasion d'écrire un article sur MQ)
Digression
Je vais donc les analyser un par un :
Étant donné que ce code est écrit dans une méthode complète, il est difficile pour Arthas de dépanner, il doit donc configurer les journaux étape par étape pour le dépannage. (Donc, s'il s'agit d'un gros morceau de logique, il est recommandé de le diviser en sous-méthodes duoge. Tout d'abord, l'idée sera claire lors de l'écriture, et il y aura un concept modulaire. Quant à la réutilisation des méthodes, je Je n'en parlerai pas davantage Opérations de base ; Deuxièmement, une fois qu'un problème survient, il sera plus facile de le dépanner, par expérience).
Enfin positionné à l'intérieur d'une boucle for.
Sans plus tarder, regardons directement le code. Comme chacun le sait, j'ai toujours été une personne qui protège le code de l'entreprise, je dois donc le simuler pour tout le monde ici. À en juger par le problème, l'enregistrement de l'objet exporté est vide
import com.google.common.collect.Lists;import java.util.List;public class Test { public static void main(String[] args) { // 获取Customer数据，这里就简单模拟
List<Customer> customerList = Lists.newArrayList(new Customer("Java"), new Customer("Showyool"), new Customer("Soga")); int index = 0;
String[][] exportData = new String[customerList.size()][2]; for (Customer customer : customerList) {
exportData[index][0] = String.valueOf(index);
exportData[index][1] = customer.getName();
index = index++;
}
System.out.println(JSON.toJSONString(exportData));
}
}class Customer { public Customer(String name) { this.name = name;
} private String name; public String getName() { return name;
} public void setName(String name) { this.name = name;
}
}复制代码 Ce code semble n'être rien, il s'agit de convertir la collection Customer en un tableau bidimensionnel de chaînes. Mais le résultat de sortie montre : 
Ceci est conforme à ce que nous avons dit. Il existe plusieurs requêtes, mais une seule est générée.
En regardant attentivement, on constate que les données de sortie sont toujours les dernières, c'est-à-dire qu'à chaque fois que la collection Customer est parcourue, cette dernière écrase la première, c'est-à-dire la partie inférieure de cet index. l'échelle n'a jamais changé, elle a toujours été 0.
De ce point de vue, notre auto-incrémentation a quelques problèmes, alors écrivons simplement un modèle
public class Test2 { public static void main(String[] args) { int index = 3;
index = index++;
System.out.println(index);
}
}复制代码Nous simplifions la logique métier ci-dessus en Pour un tel un modèle, le résultat est sans surprise 3.
Ensuite, exécutons javap et voyons comment le bytecode JVM est interprété :
javap -c Test2
Compiled from "Test2.java"public class com.showyool.blog_4.Test2 { public com.showyool.blog_4.Test2();
Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code: 0: iconst_3 1: istore_1 2: iload_1 3: iinc 1, 1
6: istore_1 7: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
10: iload_1 11: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
14: return}复制代码Ici, je parlerai brièvement des instructions du bytecode JVM ici (plus tard, j'écrirai un article en détail quand j'en ai l'occasion)
Tout d'abord, nous devons savoir qu'il y a deux concepts ici, la pile d'opérandes et la table de variables locales. Ces deux sont des structures de données qui existent dans le cadre de pile dans le. pile de machines virtuelles. , comme le montre la figure :
On peut simplement comprendre que la fonction de la pile d'opérandes est de stocker des données et de calculer des données sur la pile, tandis que la pile d'opérandes a pour fonction de stocker des données et de calculer des données sur la pile. La table de variables locales stocke certaines informations sur les variables.
Jetons ensuite un œil à l'instruction ci-dessus :
0 : Iconst_3 (poussez d'abord la constante 3 sur la pile)
1: istore_1 (出栈操作，将值赋给第一个参数，也就是将3赋值给index)
2: iload_1 (将第一个参数的值压入栈，也就是将3入栈，此时栈顶的值为3)
3: iinc 1, 1 (将第一个参数的值进行自增操作，那么此时index的值是4)
6: istore_1 (出栈操作，将值赋给第一个参数，也就是将3赋值给index)
也就是说index这个参数的值是经历了index->3->4->3，所以这样一轮操作之后，index又回到了一开始赋值的值。
这样一来，我们发现，问题其实出在最后一步，在进行运算之后，又将原先栈中记录的值重新赋给变量，覆盖掉了 如果我们这样写:
public class Test2 { public static void main(String[] args) { int index = 3;
index++;
System.out.println(index);
}
}
Compiled from "Test2.java"public class com.showyool.blog_4.Test2 { public com.showyool.blog_4.Test2();
Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code: 0: iconst_3 1: istore_1 2: iinc 1, 1
5: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
8: iload_1 9: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
12: return}复制代码可以发现，这里就没有最后一步的istore_1，那么在iinc之后，index的值就变成我们预想的4。
还有一种情况，我们来看看:
public class Test2 { public static void main(String[] args) { int index = 3;
index = index + 2;
System.out.println(index);
}
}
Compiled from "Test2.java"public class com.showyool.blog_4.Test2 { public com.showyool.blog_4.Test2();
Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code: 0: iconst_3 1: istore_1 2: iload_1 3: iconst_2 4: iadd 5: istore_1 6: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
9: iload_1 10: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
13: return}复制代码0: iconst_3 (先将常量3压入栈)
1: istore_1 (出栈操作，将值赋给第一个参数，也就是将3赋值给index)
2: iload_1 (将第一个参数的值压入栈，也就是将3入栈，此时栈顶的值为3)
3: iconst_2 (将常量2压入栈, 此时栈顶的值为2，2在3之上)
4: iadd (将栈顶的两个数进行相加，并将结果压入栈。2+3=5，此时栈顶的值为5)
5: istore_1 (出栈操作，将值赋给第一个参数，也就是将5赋值给index)
看到这里各位观众老爷肯定会有这么一个疑惑，为什么这里的iadd加法操作之后，会影响栈里面的数据，而先前说的iinc不是在栈里面操作？好的吧，我们可以看看JVM虚拟机规范当中，它是这么描述的:
指令iinc对给定的局部变量做自增操作，这条指令是少数几个执行过程中完全不修改操作数栈的指令。它接收两个操作数： 第1个局部变量表的位置，第2个位累加数。比如常见的i++,就会产生这条指令
看到这里，我们知道，对于一般的加法操作之后复制没啥问题，但是使用i++之后，那么此时栈顶的数还是之前的旧值，如果此刻进行赋值就会回到原来的旧值，因为它并没有修改栈里面的数据。所以先前那个bug，只需要进行自增不赋值就可以修复了。
Merci d'avoir lu ceci. Ce qui précède représente l'intégralité de mon processus de gestion de ce bug. Bien qu'il ne s'agisse que d'un petit bug, ce petit bug mérite quand même d'être étudié et réfléchi. Je continuerai à partager les bugs et les points de connaissances que j'ai trouvés à l'avenir. Si mes articles vous sont utiles, j'espère que vous les gars , merci encore pour votre soutien !
Recommandations d'apprentissage gratuites associées : Tutoriel de base Java
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
