Debugging Data Races
物凄い早口で、まくし立てられたので、途中メモは、無理ですた。
気付いたトコロと、知らんかったやり口を中心に、質疑応答中にメモした感じ。
String でないToken、例えば、longを、per-Threadなring-bufferに突っ込むべし。
マジで！。つまり、タイミングによって、どこがバグっとったのか検知しる。
Stringは、重いからダメなんだってさ。
Double-Chekced-lockingっぽいコードには、バグが入ってるかもねー、とか。
複数スレッドによる、読み込みと、たまに書き込まれるnullのパターンは、確かにﾔｳﾞｧｲ。
キャッシュミス系のバグは、マジで見つからない。
厳密な話、キャッシュ系は、結局の所、読み込みの無いタイミングで、書き込むしかないんじゃねぇの？
つまり、サーバ起動時にキャッシュしる。それ以外は、読込みのみにしる。
ドキュメント超重要。とかｗｗｗｗｗ
テキトーなコードを自前実装すんな、とか。
ドキュメントだって言ってるのは、Genericな超絶アイディアが無いからだって、まぁ、そりゃそうか。
java.util.concurrentは、ちゃんとテストされてるからイイよ。とか。
printfデバッグは、凄く簡単で、イイのだけど、書き込みバッファを食っちゃって、
バグが隠れるケースが、あるから気をつけるべき。まぁ、確かにそうだ。
logging系フレームワークによって、タイミングが変わるケースも、忘れないで。
つまるところ、Data Raceなバグを発見する為には、I/Oを伴うデバッグ方法はダメだっつう事か。
ring-bufferに、System.nanotime突っ込んで、後で検証する…とか…ないわー
