Java: 本番環境でのデバッグスキルを磨く - ワザノバ | wazanova
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable（EJB除く）である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
あなたとスレッドダンプ - 第八回 #渋谷java
第八回 #渋谷java で発表した「あなたとスレッドダンプ」です。 スレッドダンプの使いみち、取り方、読み方について説明しています。 スレッドダンプこわくない。
JVMTI 0.30.27
JavaTM Virtual Machine Tool Interface Reference Draft 0.30.27 はじめに JVMTI とは アーキテクチャ エージェントの作成 JVMTI エージェントのコマンド行オプション エージェントの起動 エージェントの停止 JAVA_TOOL_OPTIONS JVMTI 環境 バイトコードインストゥルメンテーション 仕様のコンテキスト 関数 JVMTI 関数のアクセス 関数の戻り値 JNI オブジェクト参照の管理 関数呼び出しの必要条件 関数の索引 メモリ管理 スレッド スレッドグループ スタックフレーム ヒープ 局所変数 ブレークポイント 監視されるフィールド クラス Object フィールド メソッド raw モニター JNI 関数の遮断 イベント管理 拡張機能機構 権限 タイマー システムプロパティ 全般 エラーコード イベント イ
#java_ja で例外とロギングについて勉強会をやるというのでいってきた＆飛び込みLTやった＆運用の視点から見たアプリケーションのログについて - たごもりすメモ
LOG.debug("nice catch!") - connpass 2012/06/27 java-ja 『LOG.debug("nice catch!")』#java_ja #javaja - Togetterまとめ blogエントリを書くまでがjava-jaだと聞いたのでとりあえず書く。超まとまってません。各スピーカーの話の内容については他の人のblogに(たぶん)書いてあるのでそっちを見るとかTogetterを眺めるとかすればよいのではないでしょうか。 主催のみなさま、および会場提供のGREEさま、ありがとうございました。そういえばGREEでの勉強会って初めて参加した気がする。六本木ヒルズの入館、だいぶ簡単になりましたね。 いってきた どっちかというとアプリケーションのコード書く人が多かったんですかね。という感じで、アプリケーションコードからいかにして例外を投げるか、それをどのよ
Javaのコマンドラインでのモニタリング／トラブルシューティングツール - CLOVER🍀
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
YouDebug -
What is YouDebug? Here is the problem; your program fails at a customer's site with an exception, but you can't (or don't want to) reproduce the problem on your computer, because it's too time consuming. If only you could attach the debugger and collect a few information, you can rapidly proceed on fixing the problem. But running a debugger at a customer's site is practically impossible; if the us
非対話的デバッガ YouDebug - 川口耕介のブログ
バグ修正はプログラマの仕事の一つですが、このうちのかなりの時間は問題を再現することに費やされます。 症状からバグの全容が推察できる時もあるのですが、多くの場合には、手元で問題を再現し、更なるデータを集めることによって始めてバグが理解されるからです。しかし、環境に依存する問題などは再現が難しい場合もあります。どうしたらよいでしょうか。 ロギングというのがよく行われる解決・予防策ですが、「デバッガを走らせて変数xの値を教えてくれればいいのに！」と思った事があるのは私だけではないと思います。ロギングと異なり、デバッガは予めプログラムに障害発生を予期するコードを埋め込んでおく必要はありません。また、呼び出し元のローカル変数をアクセスしたり、任意の式を評価したり、あるいは変数の値を変更することもできてしまいます。当たり前ですが、障害分析ツールとしてはデバッガはずっと強力だからです。 ではなぜユーザー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HotSpot JVMで動作するMission ControlとFlight Recorder
IBM Developer
log4jdbc - Project Hosting on Google Code