Javaアプリでトラブルがあったりすると、アプリケーションのログなどを読んで解析をすると思いますが、パフォーマンスやGC周りでのトラブルについては、JDKに標準付属しているコマンドを使用すると原因究明の手がかりがつかめたりすることがあります。 自分も、ちょっと前にやっていたプロジェクトでは、かなり使うことになりました。どれも有名だとは思いますが、使い方をメモしておくという意味を込めて書いておきます。 まず、今回のサンプルとして、以下のような明らかに問題のあるプログラムを用意。 Monitor.java import java.util.ArrayList; import java.util.List; public class Monitor { public static void main(String[] args) { int busyThreadNum = 3; int spar
エスカレーターでUL階に移動し、入館ゲート付近に常駐している警備の方にシールを提示すると入館できます。
今月は本題に入る前に、2012年4月26日にリリースされたJava SE 7u4について触れておきます。 Java SE 7u4では、Mac OS Xのサポートや、今まで実験的な機能とされてきたG1GCが正式にサポートされています。また、JRockitの機能のいくつかがHotSpotに移植されています。 もちろん、多くのバグフィックスやパフォーマンス向上も行われています。 これらのことから、Java SE 7が業務で使用するに十分な品質に達したと判断されたようです。今までjava.comではJava SE 7が配布されていなかったのですが、Java SE 7u4からjava.comで配布されるようになっています。 Java SE 6のEOL (End of Life)が今年(2012年)の11月に迫っているので、そろそろJava SE 7へ移行を考えていかなくてはいけないようです。 では、
そういやこれかいてなかったな。 JavaEE 6をずっとおってきて過去にいろいろと書きました。Servlet API 3.0はweb.xmlすらオプションになったり、自分で必要なものをフィルターやサーブレット等に設定するコードを自由に書けるようになったりしたのがでかいです。ELにメソッドが使えるようになったのもかなりきてますね。 まずはGlassfish V3をお試しあれ。最も軽いJava EEアプリケーションサーバーです。 高速なデプロイ Glassfish V3はEclipse、NetBeans、IDEAともに対応していてすごい簡単に開発が出来るのがわかると思います。え?JavaEEサーバーは重いって?300msとかでデプロイできる環境が遅いというのならばそうなのでしょう。デプロイ時間はTomcatとかわりません。それどころかデプロイするファイルが減る可能性もありますので軽くなる場合も
TEST http://d.hatena.ne.jp/devbankh/201001 モックやスタブを使った効率的なユニットテスト http://d.hatena.ne.jp/devbankh/201002 モックとスタブの違い コミュニケーション http://d.hatena.ne.jp/devbankh/20051124 簡単かつ効果的に話すために "モックオブジェクト"という言葉は、テストのために本物のオブジェクトをまねる特殊なオブジェクトを表す言葉として定着した。しかしモックという言葉は元々スタブをキャッチーにしたものでなく、[スタブを使ったのとは別の] ユニットテスト方法を用いるためのものなのだ。この記事では、モックオブジェクトのファンに好まれる相互作用中心のテストと、よく行わている状態中心のテストスタイルとの違いを説明するために、モックとスタブの違いについて掘り下げる。 目次
Java EE環境では基本的にスレッドの生成は許されていません。この制限はEJB仕様書に記述されており、ブループリントなど他のドキュメントにも記載されています。これらの制限はかなり古い時代に考えうる最大の制限を記述したものであり、「ファイルにアクセスしてはならない」など今となってはあまり現実的ではない記述も多くなっています。しかしながら、「スレッドを生成してはならない」というのは依然多くのコンテナに適用される現在も有効な制限であり、実際にスレッドの生成などを行うと誤動作するケースがあります。今回は、なぜこのスレッドの制限があるのか、現実的にどうすれば良いのか解説します。 コンテナは様々なものをスレッドに結びつけて管理しています。様々なものというのは例えばセキュリティ、トランザクション、データソースなどのコンテナリソースです。コードのほうがイメージしやすいでしょうから、以下に擬似コードを挙げ
Thread.stop が推奨されないのはなぜですか 本質的に安全ではないからです。スレッドを止すると、そのスレッドがロックしたすべてのモニターのロックが解除されます。(ThreadDeath 例外がスタックまで伝わると、モニターのロックが解除される。)これらのモニターによって以前保護されていたオブジェクトが整合性のない状態になると、ほかのスレッドも、これらのオブジェクトが整合性のない状態にあると見なします。そのようなオブジェクトは、「壊れた」オブジェクトと呼ばれます。壊れたオブジェクトに対してスレッドが操作を実行すると、予期しない結果になる可能性があります。この動作は、微妙で検出が困難な場合と、はっきりと通知される場合があります。チェックされないほかの例外とは異なり、ThreadDeath は、スレッドをそのまま強制的に終了します。このため、ユーザーは、プログラムが壊れる可能性を警告され
The Oracle Java Archive offers self-service download access to some of our historical Java releases WARNING: These older versions of the JRE and JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production. For production use Oracle recommends downloading the latest JDK and JRE versions and al
2012年4月4日~5日に開催されたイベント、「JavaOne Tokyo 2012」のセッションで使用された資料を公開しています。この資料に記載されている内容は、4月5日時点の情報です。 ※資料欄に、”-”と記載されているセッションにつきましては、申し訳ございませんが資料の提供はございません 4月4日(水)
男子たるものJVMと仲良くせねばなりません。 仲良くなるにはまず相手のことを良く知ることから始めましょう。 Coreダンプを読むには 至極一般的なCoreといえばこれ。基本ツールに食わせてうはうは言いながら見るといい。 IBMのダンプアナライザはここからDLできる。 http://www.alphaworks.ibm.com/tech/jca/download 侍もみやすい。 http://yusuke.homeip.net/samurai/ja/index.html HeapDumpを読むには Coreだけじゃ満足できない時はHeapも見る。てかJavaHeap内のメモリ使用状況の解析をしたいならHeapDumpをみなくちゃ始まりません。 普通にHeapDumpを解析するならGUIでみるのが一番。 IBMからでてるHeapAnalyzerを使うのがベター。 メモリが少ないと動かなくなるの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く