ラベル java の投稿を表示しています。 すべての投稿を表示
ラベル java の投稿を表示しています。 すべての投稿を表示

2013年8月19日月曜日

ScheduledExecutorServiceが停止した。

なんの前触れもなく、ScheduledExecutorServiceが停止してしまった。
実行のため、invokeしていたThreadクラスに問題があったのかどうか調べたけど、そうでも無さそう。

そんなとき、ScheduledExecutorServiceが動かなくなるという現象について書かれた記事を見つけた。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7139684

どうやらスレッドを起動するために利用している OSレベルの処理でシグナル受信に失敗し、起動するはずのスレッドが起動しないままになってしまっているようだ。
しかも、一度失敗すると二度と起動しないという。。。。。


みたところ、回避策は提示されていないので、この現象にはまったら、プロセスの再起動だろうか。
shutdown()と、submit()で、復旧できるといいんだけど。

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");
}
}

2013年7月18日木曜日

Tomcatのsharedローダのクラスを監視する Java Intaractive Profiler(JIP)の備忘録

最近、プロファイラを利用してアプリの挙動の確認を行った。hprofでなく、JIPを利用しました。
利用したのは現在(2013年7月)のバージョン(1.2)です。

使い方は色々なページで説明していたり、ドキュメントが付属しているのでなんとなく読めばわかりますが、ちょっとわからなかったことを備忘録として書いておきます。

参考:http://d.hatena.ne.jp/goking/20101125/p1


  • Tomcatのアプリと、sharedloaderに指定したライブラリをプロファイルする
どうしても見つけられなかったので、書き残しておきます。

通常、Webアプリのプロファイルをする場合は、プロファイラとしてwebapp.profile.propertiesを指定しますが、こいつを少し編集します。

もともとの内容の一部

#
# Class Loader filters for different runtine environments
# (The system will cycle through these until it finds one that
# can filter in the current environment)
#
ClassLoaderFilter.1=com.mentorgen.tools.profile.instrument.clfilter.WebAppClassLoaderFilter
ClassLoaderFilter.2=com.mentorgen.tools.profile.instrument.clfilter.StandardClassLoaderFilter


 書きなおした結果

#
# Class Loader filters for different runtine environments
# (The system will cycle through these until it finds one that
# can filter in the current environment)
#
ClassLoaderFilter.1=com.mentorgen.tools.profile.instrument.clfilter.TomcatInternalClassLoaderFilter
ClassLoaderFilter.2=com.mentorgen.tools.profile.instrument.clfilter.StandardClassLoaderFilter

 ClassLoaderFilter.1 をTomcatInternalClassLoaderFilterに変えます。これで、sharedloaderのクラスもプロファイル対象となりました。

あとは、excludeの項目に、見たくないパッケージを記載しておけば、ごちゃごちゃしなくなります。

Javaネイティブのクラスをプロファイル対象にできないかどうかは探し中です。
見つかるのかわからないですが....

他にもいくつかプロファイラがありますが、どうやって使うのかはわかりません。
http://www.java2v.com/Open-Source/Java-Document/Profiler/JIP/com.mentorgen.tools.profile.instrument.clfilter.htm

もうひとつついでに。
ダウンロード先のSourceForgeでは、最初あやまってjip-src-1.2.zipをダウンロードしました。
間違ってはいないんですが、JipViewerが見つかりませんでした。
jip-1.2.zipをダウンロードしたらちゃんとありました。

http://sourceforge.net/projects/jiprof/files/jip/1.2/