java.util.TimerとThread.Sleep(long)
2005年7月4日・エ)ふーむ。
再起動とか、行われた時に安全に終了されるのかしら、とか。
・エ・)while(true){} の中で、Thread.Sleep(long)を使うけど、具体的に、どのぐらいの数値にしておくといいのかしら。とか
・エ)考えちゃう。
Thread.Sleep(long)のlongの値を大きくしたら、それだけ、実行する時間に到達していない間、リソースを解放できる効果があるから、必要なのだ。
でも、数値次第では、実際に実行を開始する時間が大きくずれてしまい、そのずれが時間の経過とともにどんどん成長して行く気がするのだけど、どうだろう。
一日1回の処理だとすると、1日1回ループしたらいいだけだし、
スリープは1日させてればいいのか???
だが、次にスレッドが目が覚めるのは、処理に要した時間+1日後。
・エ)実際に処理させたい時間より、処理に要した時間分、毎回加算されてずれが産まれてくる。
・エ)半日に設定すると、大きな誤差は1日まで成長し、ある日、2度分のjava.util.TimerTaskの子クラスを実行するのではないか。
・エ・)1時間にすると、誤差は1時間までで、収まるはず。
7時に処理を実行すると設定して、ずれの成長で6時59分に目覚めた。実際の処理は次のスレッドの目覚める時間である7時59分に実行。処理にかかった時間が1分以上なら、次の目覚めは、7時以降になるので、ずれは前回のずれよりも短くなる。
・エ)1分にしたら、誤差は1分にとどまるはず。
・エ)ほんとは、処理にかかる平均時間分をスリープさせる時間にしたらいいのかもしれない。ああ、でも、1時間以上もかかる処理の場合、この設定では、1時間以上のずれに成長させてしまうな。処理にかかる時間は関係ないか。
=エ)そんなに時間がかかる処理はスレッドにして、実行させれば、タイマーにかかる誤差はスレッドの生成にかかる時間だけになるはず。
でも、これやると、他の処理との連携を取らすのに、マルチスレッドなデザインパターンを使わないといけなくなるわな。
=エ=)仕組みに対する検証が推測ばかりだw
1分のスリープでいいかな。。。
5分でも大差はないわなw
10分でも。。。
再起動とか、行われた時に安全に終了されるのかしら、とか。
・エ・)while(true){} の中で、Thread.Sleep(long)を使うけど、具体的に、どのぐらいの数値にしておくといいのかしら。とか
・エ)考えちゃう。
Thread.Sleep(long)のlongの値を大きくしたら、それだけ、実行する時間に到達していない間、リソースを解放できる効果があるから、必要なのだ。
でも、数値次第では、実際に実行を開始する時間が大きくずれてしまい、そのずれが時間の経過とともにどんどん成長して行く気がするのだけど、どうだろう。
一日1回の処理だとすると、1日1回ループしたらいいだけだし、
スリープは1日させてればいいのか???
だが、次にスレッドが目が覚めるのは、処理に要した時間+1日後。
・エ)実際に処理させたい時間より、処理に要した時間分、毎回加算されてずれが産まれてくる。
・エ)半日に設定すると、大きな誤差は1日まで成長し、ある日、2度分のjava.util.TimerTaskの子クラスを実行するのではないか。
・エ・)1時間にすると、誤差は1時間までで、収まるはず。
7時に処理を実行すると設定して、ずれの成長で6時59分に目覚めた。実際の処理は次のスレッドの目覚める時間である7時59分に実行。処理にかかった時間が1分以上なら、次の目覚めは、7時以降になるので、ずれは前回のずれよりも短くなる。
・エ)1分にしたら、誤差は1分にとどまるはず。
・エ)ほんとは、処理にかかる平均時間分をスリープさせる時間にしたらいいのかもしれない。ああ、でも、1時間以上もかかる処理の場合、この設定では、1時間以上のずれに成長させてしまうな。処理にかかる時間は関係ないか。
=エ)そんなに時間がかかる処理はスレッドにして、実行させれば、タイマーにかかる誤差はスレッドの生成にかかる時間だけになるはず。
でも、これやると、他の処理との連携を取らすのに、マルチスレッドなデザインパターンを使わないといけなくなるわな。
=エ=)仕組みに対する検証が推測ばかりだw
1分のスリープでいいかな。。。
5分でも大差はないわなw
10分でも。。。
コメント