java Basic Tutorial 列では、i によって引き起こされるバグを紹介します。

皆さん、こんにちは。毎日バグを書いて修正している者として、今日は數(shù)日前に修正されたばかりの事故を紹介します。どこにいても常にバグがたくさんあることを認(rèn)めざるを得ません。

原因

この話は數(shù)日前に始まりました。あまり一般的に使用されておらず、ユーザーによって報告されたエクスポート機能がありました。條件は でした。エクスポートされたデータは 1 つだけですが、実際には條件に従って大量のデータがクエリされており、ページ上でも大量のデータがクエリされています。 (この問題は修正されたため、當(dāng)時の Kibana ログはもう見つかりません。) そこで、私は仕事をやめて、この問題を調(diào)査することにしました。

分析

問題の説明によると、この問題は次の狀況でのみ発生する可能性があります。

1. に基づいてクエリされたレコードは 1 つだけです。検索條件
2. クエリされたデータに対して関連するビジネス処理を?qū)g行し、最終結(jié)果は 1 つだけになります。
3. ファイル エクスポート コンポーネントの論理処理後の結(jié)果は 1 つだけです。
   

余談
これを書いた後、MQメッセージ損失の原因の分析という古典的な面接の質(zhì)問を突然思い出しました。ははは、実はいくつかの角度から大まかに分析されています。 (機會があれば MQ についての記事を書きます)
余談

ということで、一つずつ分析していきます:

1. クエリで取得できる関連業(yè)務(wù)のSQLと対応するパラメータを検索します データは複數(shù)あるため、最初の狀況は除外できます。
2. 中間ビジネスには、関連する権限、データの機密性などが含まれます。これらを解放した後も、データは 1 つだけです。
3. ファイル エクスポート コンポーネントがデータを受信すると、出力されるログにもエントリが 1 つだけ表示されます。これは、関連するビジネスのロジックに問題があることを意味します。

このコードはメソッド全體に記述されているため、Arthas によるトラブルシューティングが困難です。そのため、トラブルシューティングのためにログを段階的に設(shè)定する必要があります。 (そのため、大きなロジックの場合は、duoge のサブメソッドに分割することをお勧めします。まず、作成時にアイデアが明確になり、モジュールの概念が存在します。メソッドの再利用については、基本操作 ; 次に、経験から言えば、問題が発生するとトラブルシューティングが容易になります)。
最終的に for ループ內(nèi)に配置されます。

コード

早速、コードを直接見てみましょう。ご存知のとおり、私は常に會社のコードを守る人間でしたので、ここにいる全員のためにそれをシミュレートする必要があります。問題から判斷すると、エクスポートされたオブジェクト レコードは空です

import?com.google.common.collect.Lists;import?java.util.List;public?class?Test?{????public?static?void?main(String[]?args)?{????????//?獲取Customer數(shù)據(jù)，這里就簡單模擬
????????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;
????}
}復(fù)制代碼

このコードは何もないようで、Customer コレクションを文字列の 2 次元配列に変換するものです。しかし、出力結(jié)果は次のようになります: これは私たちが言ったことと一致しています。複數(shù)のクエリがありますが、出力されるのは 1 つだけです。
よく見ると、出力データは常に最後のデータであることがわかります。つまり、Customer コレクションが走査されるたびに、後者が前者を上書きします。つまり、このインデックスの下位部分は、スケールは決して変更されず、常に 0 です。

モデリング

自己インクリメントにはいくつかの問題があるようですので、単純にモデルを作成しましょう

public?class?Test2?{????public?static?void?main(String[]?args)?{????????int?index?=?3;
????????index?=?index++;
????????System.out.println(index);
????}
????
}復(fù)制代碼

上記のビジネス ロジックを次のように単純化します。このようなモデルの場合、結(jié)果は當(dāng)然のことながら 3 です。

説明

次に、javap を?qū)g行して、JVM バイトコードがどのように解釈されるかを見てみましょう:

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}復(fù)制代碼

ここで、JVM バイトコード命令について簡単に説明します (後で説明を書きます)機會があれば詳しく説明します)
まず、ここにはオペランド スタックとローカル変數(shù)テーブルという 2 つの概念があることを知っておく必要があります。これら 2 つは、仮想マシンのスタック フレーム內(nèi)のデータ構(gòu)造です。

# オペランド スタックの機能はスタックにデータを格納し、データを計算することであり、ローカル変數(shù)はtable は変數(shù)に何らかの情報を格納するためのものです。
次に、上記の命令を見てみましょう:
0: iconst_3 (最初に定數(shù) 3 をスタックにプッシュします)

1: istore_1 (出棧操作，將值賦給第一個參數(shù)，也就是將3賦值給index)

2: iload_1 ?(將第一個參數(shù)的值壓入棧，也就是將3入棧，此時棧頂?shù)闹禐?)

3: iinc 1, 1 (將第一個參數(shù)的值進行自增操作，那么此時index的值是4)

6: istore_1 (出棧操作，將值賦給第一個參數(shù)，也就是將3賦值給index)

也就是說index這個參數(shù)的值是經(jīng)歷了index->3->4->3，所以這樣一輪操作之后，index又回到了一開始賦值的值。

延伸一下

這樣一來，我們發(fā)現(xiàn)，問題其實出在最后一步，在進行運算之后，又將原先棧中記錄的值重新賦給變量，覆蓋掉了 如果我們這樣寫:

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}復(fù)制代碼

可以發(fā)現(xiàn)，這里就沒有最后一步的istore_1，那么在iinc之后，index的值就變成我們預(yù)想的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}復(fù)制代碼

0: iconst_3 (先將常量3壓入棧)
1: istore_1 (出棧操作，將值賦給第一個參數(shù)，也就是將3賦值給index)
2: iload_1 ?(將第一個參數(shù)的值壓入棧，也就是將3入棧，此時棧頂?shù)闹禐?)
3: iconst_2 (將常量2壓入棧, 此時棧頂?shù)闹禐?，2在3之上)
4: iadd (將棧頂?shù)膬蓚€數(shù)進行相加，并將結(jié)果壓入棧。2+3=5，此時棧頂?shù)闹禐?)
5: istore_1 (出棧操作，將值賦給第一個參數(shù)，也就是將5賦值給index)

看到這里各位觀眾老爺肯定會有這么一個疑惑，為什么這里的iadd加法操作之后，會影響棧里面的數(shù)據(jù)，而先前說的iinc不是在棧里面操作？好的吧，我們可以看看JVM虛擬機規(guī)范當(dāng)中，它是這么描述的:

指令iinc對給定的局部變量做自增操作，這條指令是少數(shù)幾個執(zhí)行過程中完全不修改操作數(shù)棧的指令。它接收兩個操作數(shù)： 第1個局部變量表的位置，第2個位累加數(shù)。比如常見的i++,就會產(chǎn)生這條指令

看到這里，我們知道，對于一般的加法操作之后復(fù)制沒啥問題，但是使用i++之后，那么此時棧頂?shù)臄?shù)還是之前的舊值，如果此刻進行賦值就會回到原來的舊值，因為它并沒有修改棧里面的數(shù)據(jù)。所以先前那個bug，只需要進行自增不賦值就可以修復(fù)了。

最後に

ご覧いただきありがとうございます。上記は、このバグに対処する私のプロセス全體です。これは単なる小さなバグですが、この小さなバグにも學(xué)習(xí)し、検討する価値があります。今後も私が見つけたバグやナレッジ ポイントを共有していきたいと思います。私の記事がお役に立てば、皆さんも幸いです。$\color{red}{クリックしてフォロー}$ $\color{red}{いいね!}$ 関連する無料學(xué)習(xí)の推奨事項:

Java 基本チュートリアル

以上がi++ に起因するバグを解決するの詳細內(nèi)容です。詳細については、PHP 中國語 Web サイトの他の関連記事を參照してください。