java Basic Tutorial column introduces bugs caused by i.
Hello everyone, as someone who writes and fixes bugs on a daily basis, today I will bring you an accident that was just fixed a few days ago. I have to admit that there are always so many bugs wherever I am.
The story started a few days ago. There was an export function that was not very commonly used and was reported by users, no matter what the conditions were. , there is only one piece of data exported, but in fact there is a lot of data queried according to the conditions, and a lot of data is also queried on the page. (This problem has been fixed, so the Kibana logs at that time can no longer be found) So I put down my work and jumped in to look at this problem.
From the description of the problem, it can only occur in the following situations:
Digression
After writing this, I suddenly thought of a classic interview question, analysis of the cause of MQ message loss. Hahaha, in fact, it is roughly analyzed from several angles. (I will write an article about MQ when I have the opportunity)
Digression
So I will analyze them one by one:
Since this code is written in the entire method, it is difficult for Arthas to troubleshoot, so we have to set up the log step by step for troubleshooting. (So, if it is a large piece of logic, it is recommended to split it into duoge sub-methods. First of all, the idea will be clear when writing, and there will be a modular concept. As for method reuse, I won’t mention it more. Basic operations ; Second, once a problem occurs, it will be easier to troubleshoot, speaking from experience).
Finally positioned inside a for loop.
Without further ado, let’s look at the code directly. As we all know, I have always been a person who protects the company's code, so I have to simulate it for everyone here. Judging from the problem, the exported object record is empty
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;
}
}复制代码This code seems to be nothing, it is to convert the Customer collection into a two-dimensional array of strings. But the output result shows: 
This is in line with what we said. There are multiple queries, but only one is output.
Looking carefully, we can find that the output data is always the last one. That is to say, every time the Customer collection is traversed, the latter overwrites the former. That is to say, the lower part of this index The scale has never changed and is always 0.
It seems that our self-increment does have some problems, so let’s simply write a model
public class Test2 { public static void main(String[] args) { int index = 3;
index = index++;
System.out.println(index);
}
}复制代码We simplify the above business logic into For such a model, the result is unsurprisingly 3.
Then let’s execute javap and see how the JVM bytecode is interpreted:
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}复制代码Here I will briefly talk about the JVM bytecode instructions here (later I will write an article in detail when I have the opportunity)
First of all, we need to know that there are two concepts here, the operand stack and the local variable table. These two are some data structures in the stack frame in the virtual machine stack. , as shown in the figure:
We can simply understand that the function of the operand stack is to store data and calculate data in the stack, while the local variable table is to store variables some information.
Then let’s take a look at the above instructions:
0: iconst_3 (first push the constant 3 onto the stack)
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，只需要进行自增不赋值就可以修复了。
Thank you all for seeing this. The above is my entire process of dealing with this bug. Although this is just a small bug, this small bug is still worth learning and thinking about. I will continue to share the bugs and knowledge points I found in the future. If my article is helpful to you, I also hope you guys
Related free learning recommendations:
The above is the detailed content of Solve a bug caused by i++. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
