なんの前触れもなく、ScheduledExecutorServiceが停止してしまった。
実行のため、invokeしていたThreadクラスに問題があったのかどうか調べたけど、そうでも無さそう。
そんなとき、ScheduledExecutorServiceが動かなくなるという現象について書かれた記事を見つけた。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7139684
どうやらスレッドを起動するために利用している OSレベルの処理でシグナル受信に失敗し、起動するはずのスレッドが起動しないままになってしまっているようだ。
しかも、一度失敗すると二度と起動しないという。。。。。
みたところ、回避策は提示されていないので、この現象にはまったら、プロセスの再起動だろうか。
shutdown()と、submit()で、復旧できるといいんだけど。
2013年8月19日月曜日
2013年8月17日土曜日
new Date().getTime() と System.currentTimeMillis() どちらが早いのか を調べてみた
先ほどの投稿から、ちょっと気になったので調べてみた。
大したことではないですけど、時間を取得したり計測するのに、よく使うんじゃないかと思いますが、どちらが高速なのか。が気になって調べてみました。
結果から言うと、System.currentTimeMillis()の方が倍高速です。
どちらも1000000回実行した時の合計時間です。
new Date().getTime() 188ms
System.currentTimeMillis() 91ms
インスタンス生成に時間がかかるのでしょうかね。
1000000回なので、どっちを使おうがあまり関係ない位だと思いますが、どちらかというと軽いのでSystem.currentTimeMills()を使ったほうが余計なことしないのでいいかなと。思いました。
計測環境を記載していないのは、実効速度を調べたかったのではなく、どちらが早いかを確認したかっただけなので載せてないです。マシンによって差があるというのであれば考えますが.....
OSはWindows Vistaです。
ソースは汚いですが、以下です。
import java.util.Arrays;
import java.util.Date;
import java.util.Iterator;
public class PerformanceSample {
/**
* @param args
*/
public static void main(String[] args) {
ExecuterIf process = null;
// NewDate
process = new NewDate();
PerformanceMesure.execute(process);
// currentTimeMillis
process = new SystemCurrent();
PerformanceMesure.execute(process);
}
}
class NewDate implements ExecuterIf{
@Override
public void exec(){
long time = new Date().getTime();
}
}
class SystemCurrent implements ExecuterIf{
@Override
public void exec(){
long time = System.currentTimeMillis();
}
}
interface ExecuterIf{
public void exec();
}
class PerformanceMesure{
public static void execute(ExecuterIf process){
long start = 0L;
long end = 0L;
long elapse = 0L;
start = System.currentTimeMillis();
for(int m = 0 ; m < 1000000; m ++)
process.exec();
end = System.currentTimeMillis();
elapse = end - start;
System.out.println(elapse + "ms");
}
}
Exceptionを利用したループのハンドリング性能
Effective Java の Item57 にあるwhileループのやってはいけない例について調べてみました。
たぶん、こんな使い方する人はいないんだと思いますが、悪いことしかないってことを確かめたかったので。
調べたのは性能です。ソースを見るとわかりますが、エラーなのかループの終了なのか判断できないため、使う人はいないと思います。
以下の2つの性能を比較しました。
例1)
例1 230ms
例2 2ms
こんなに差があるとは思ってなかったですが、100倍違います。
EffectiveJavaでは、現在のJVMを利用した場合は遅い。とか書いてありましたが、昔は早かったのでしょうか。
そうだとすると、悪い書き方をしたソースがあるかもしれないですよね....
この例だけでは言えませんが、正当な作り方をしておくと、のちのち性能が上がるかも知れない。
ということでしょうか。
その場しのぎのコーディングはやめようと思います。
たぶん、こんな使い方する人はいないんだと思いますが、悪いことしかないってことを確かめたかったので。
調べたのは性能です。ソースを見るとわかりますが、エラーなのかループの終了なのか判断できないため、使う人はいないと思います。
以下の2つの性能を比較しました。
例1)
// Horrible abuse of exceptions. Don't ever do this!例2)
try{
int i = 0;
while(true)
range[i++].climb();
}catch{ArrayIndexOutOfBoundsException e{
}
int i = 0;配列のサイズは100、試行回数は1万回。累積時間(ms)を計測した結果です。
while(range. length > i)
range[i++].climb();
例1 230ms
例2 2ms
こんなに差があるとは思ってなかったですが、100倍違います。
EffectiveJavaでは、現在のJVMを利用した場合は遅い。とか書いてありましたが、昔は早かったのでしょうか。
そうだとすると、悪い書き方をしたソースがあるかもしれないですよね....
この例だけでは言えませんが、正当な作り方をしておくと、のちのち性能が上がるかも知れない。
ということでしょうか。
その場しのぎのコーディングはやめようと思います。
登録:
投稿 (Atom)