デバッグ一度覚えておいてください
でHITソフトウェア構造LAB6では、彼は川を渡っ複数のスレッドのサルと意思決定プロセスをシミュレートするために私達に尋ねました。
この実験のテクトニックな思考が、実際には比較的簡単である各決定サルのためのスレッドを作成することで、各サルは、独自の意思決定を持っていますが、すべてのサルは川を共有します。これは、競合状態があることを意味します。
2頭のサル同じ位置を選択するための決定は、結果はプログラムがクラッシュしながら、重なる位置に至るまで、お互いにぶつかるだろうしながらそれは、場合であってもよいです。
これを避けるために、我々はまた、効率を改善しながら、スレッドセーフできる限り確保するために慎重な計画が必要です。
マルチスレッドプログラミングを学ぶ実験の主な安全上の目的です。
唯一のGUIを達成するために必要な実験では、アニメーションのための必要はありませんが、私はもっと忙しいので、ちょうどそれを試してみることにしたかったので、私は猿をアニメーション川のコースを横断しようとすることを決めました。
アニメーション効果を達成するための予備
私の考えは、川を渡って猿を描画するためのJComponentを使用することです。
ガイドブック上の要件は、つまり、サルの全てを単位として意思決定を行うために1秒です、と言う、すべてのサルはサルが動かなかった場合でも、一回1秒の状態に更新されます。
あなたは猿のそれぞれを移動するプロセスを表示していたされた30猿がある場合は、その後、それが30回を再描画されるように1秒を意味し、完全なアニメーションを、実現したい場合は、サルの数が1以下の、通常に影響を与えるにバインドされ判決の決定計算は、サルのシミュレーションの動きが正確ではないので、これは望ましいことではないでしょう。
だから私は、毎秒考えて決断する前に、すべてのサルを運転、タイマーを再描画一度呼び出して、あなたは、リソースの消費を最小限に抑えることができます。
基本的な考え方は、このプログラミングです。
ラダー位置サルリストの地図<整数、整数>上のデータ構造を維持し、キーマップは、サルにおけるラダーの座標値が、値はサルのIDです。異なる要素は、はしごのリストを表し
毎秒開始し、読み出しクラスVisualMonkeyのリストと、コンポーネント上に描画するために、コンポーネントを次に座標値に変換し、そして。
この実験後のいくつかは、私は確かに1のコードを見て戻ってくるのは嫌だにもかかわらず支払う後これは元々、容易に拡張できるように設計されました。
基本的な考え方は非常に簡単です。
プログラムの後に書かれた、それを実行しようとします
。。。。。。えっ？なぜ重複しません。
非常に深刻な問題がありました、同じサルはまた、梯子上の位置の数で表示され、それが何が悪かったのかである必要があります
調査のバグ
componnet問題？
私はこのバグの最初の反応は、唯一の新しいパターンを描画するために、失敗した再描画--componentで、古いパターンを打たされていません見ました。
この推測の後ろに正当証明したが、私は間違ってここにいくつかのうちに誓った、本当に多くの時間を無駄にしました。
私はトラバース関連するすべての再描画方法を解決することはできません一度呼び出さ、外含まれる成分からパネルまで、更新は試してみましたが、塗り替え、検証、再検証を含め、ジャワのコンポーネントに関する知識の多くは再描画インターネットを検索しますこの問題。
次いで、Iが再描画次いでpaintComponentメソッドの内部成分Gに空である、とすることを試み、失敗しました
それから私は、まだ失敗し、最初からすべてをコンポーネントオブジェクトを再作成しようとすると、
通常のロジックによると、構成部品は全く問題、他の場所でバグアウトもありませんが、LAB3種類あるため、大きなスイング不満を持っているので、とにかく私は時間を費やし、それを転覆したいはずです、コードがされています私は理解していない変更するには、魔法、私は最終的に他の道路を探索することにしました。
忘れられた更新
私はおそらく、コンポーネントの再描画を忠実に実行すること、疑問に思うようになった、と古い猿の位置が削除されない可能性があります。
ADTサルのテストの時以来、彼らは完全にミッションを完了したので、私はまだ問題がないと思います。
私は何を忘れてしまったように見える、待って
???
ADTは間違っていない、コンポーネントが間違っていない、問題がある......？
......
ああ、それはそれでした。
ブレークポイントはVisualMonkeyクラスを発見し、実際に座標値が間違っていた変換するリストから種が、私は唯一のマップが置かれたことがわかったが、以前はクリアされませんでした
これは、スレッドセーフによって引き起こされますが、実際にマルチスレッドの複雑さは、それが簡単にこれらの問題を無視することができますされていません。
各変換の前に必要としているようで、マップの空
画像特殊性
のが見て猿を実行してみましょう
...... ??
どのようにサルが重複していますか？
サルの目の前で見られる注意深い観察は、どこに問題がある私はおそらく知っている、何の名前、サルの画像だけではありません。
为了追求动画效果，我是使用emoji图片来表示猴子的。由于Image对象不属于Graphic对象
说的就是这个参数g
在paintComponent里面，我都是直接调用add方法来添加图片的
而那些线条之类的元素是添加到Graphics对象里的：
调用repaint的时候，Graphics对象里的线条都被清空了，但是图片并没有被删除。
为了解决这个问题，我设置了一个set，每次把图片加到component上面的时候，同时把它们添加进这个set里
然后在每次repaint的时候，都要将component上的所有图片清空一次
现在应该没有问题了吧？
跑一下猴子看看：
终于解决了。
感想
在debug的过程中，应当冷静分析
有时候要认真思考问题出现的地方，比如说我执迷于打倒component，就忽视了别的地方。