圧力テストによるBug(二)--Bug

詳細
最近のプロジェクトではセキュリティフレームワークとしてAcegiが適用され、プロジェクトの試運転中に隠された深いBugが発生しました.しばらく実行すると、URLリソース列の制御機能が失効します.acegiの最新バージョンが更新されてもBugは除外されません.
このバグの発生はしばらく運転してから発見する必要があるため、検査するのは比較的に困難で、そのためテストツールを通じて一定時間の圧力テストを行った後に故障の発生を再現する必要がある!
圧力テストによるBug(一)--テストの過程でテストの手順を紹介しました.以下、このBugの検査過程を紹介して、参考にします.
 
MyEclipseのデバッグモードで実行されるWebアプリケーションでは、ブレークポイントを設定してワンステップデバッグを行うことができ、ブレークポイントを設定するのは簡単で、コード行の前にマウスの左ボタンをダブルクリックするだけです.プログラムがこのコードを実行すると実行が一時停止し、Debugモードウィンドウでプログラムの実行状態を観察できます.
acegiによるurlの制御はfilterで行われているので、AbstractFilterInvocationDefinitionSourceを継承したカスタムfilterにブレークポイントを設定しました.
ブレークポイントの変数値を観察することでurls変数の値が正常ではないことがわかりました.この値はバックグラウンドで管理されているすべてのURLリソースであるべきです.今ではすべて同じURLになっています.問題はここにあります.何が変数値の乱れを招いたのでしょうか.次の方法が私の注意を引き起こしました.

		// url
		orderUrls(urls);

	/**
	 *  url 
	 * @param urls
	 */
	private  void orderUrls(List urls) {
		Collections.sort(urls);
		Collections.reverse(urls);
	}

この方法はurlsをアルファベット順に逆順序に並べ替えた.Collectionsのためである.sortは静的手法であり,実行時に値パラメータが1箇所のメモリアドレスで動作するはずであるため,同時動作時には必ず互いに干渉して重なるソート動作が発生しurls変数値の乱れをもたらす!
そこで私はこの方法にsynchronizedキーワードを付けて、複数のスレッドが同時にこの方法にアクセスすることを防止しました.

	/**
	 *  url 
	 * @param urls
	 */
	private  synchronized  void orderUrls(List urls) {
		Collections.sort(urls);
		Collections.reverse(urls);
	}

更に1ラウンドの圧力テストを経て、更に類似の問題が現れなくて、これでこのBugは成功に解消します!
この欠陥は、後でプログラミングするときにスレッドの同時操作の影響に注意し、影響のある場所でsynchronizedキーワードを使用して複数のスレッドが同時にコードにアクセスすることを防止することに注意しなければならないことを示しています.
同時に,圧力試験の必要性は,適切な圧力試験を行わないと,より隠蔽された欠陥,特にマルチスレッド同時動作の応用が発見されない可能性があることが分かった.圧力テストでは,開発したシステムの性能がどのようになっているのか,動作が安定しているのか,実際の応用環境を満たすことができる顧客のアクセス量を考察することもできる.