あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が
去る 9 月 20 日（土）に、第八回 #渋谷java というイベントで LT してきました。（第八回 #渋谷java でスレッドダンプについてお話ししました - この国では犬が） あとあと自分で参照したり、スレッドダンプを知らない人に見せたりしたい内容でもあるので、ブログとしてまとめておきます。 スレッドダンプとはなにか スレッドダンプは、ひとことで言うと「Java のスレッドのスナップショット」ということになります。 スレッドダンプを取得することで、取得した瞬間に JVM 上でどのような処理が実行されているのかを一覧して、調査することができます。 具体的には、その瞬間に存在している各スレッドの名前、状態、スタックトレース等を見ることができます。 スレッドダンプはなんの役に立つのか プログラムが遅いとき・フリーズしたとき 一つには、プログラムが遅いとき・フリーズしたときの原因調査に役立ち
Javaのスレッドダンプの読み方 - ablog
あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が が非常にわかりやすく、自分でブログエントリを書く必要はないが、Oracle Database や Linux の性能分析に携わる者の観点から Java のスレッドダンプについて整理してみた。具体的なスレッドダンプの分析方法はサポートエンジニアが語るWebLogic Serverトラブルシュートのノウハウがとてもわかりやすい。 WebLogic のスレッドダンプの見方については id:yamadamn さんの スレッドダンプから見るWebLogic Serverの世界 #javaee - yamadamnのはてな日記 がわかりやすい。 スレッドダンプとは Javaのスレッドのスナップショット。 取得した瞬間のJava仮想マシン(JVM)内に存在するスレッド（ID、名前、状態、タイプなど）とコールスタックを見ることができる。
jstack でスレッドダンプを取る - にょきにょきブログ
jstack というツールがある。このツールは、現在実行中の Java プロセスのスレッドの状態を取得出来るツールだ。 思ったように性能が出ない時やデッドロックっぽい現象が発生した際はこのツールを使ってスレッドの状態を取得、つまりスレッドダンプを得て、そこから解決の糸口を探す。 今回のサンプルコードは下記コード。 少し長いが、Thread1 と Thread2 クラスはほぼ同一だ。違うのは、リソースをロックする順序。Thread1 クラスは resource1, resource2 の順にロックするが、Thread2 クラスは resource2, resource1 の順にロックする。つまり、これら２つのクラスを同時に実行するとデッドロックを起こす。 public class DeadLockTest { public static Object resource1 = new Obje
C++ マルチスレッド 入門
エラーハンドリングとはどうあるべきかについての考察。 Boost.勉強会 #3 関西 ( http://kokucheese.com/event/index/4335/ )にて発表。
あなたとスレッドダンプ - 第八回 #渋谷java
第八回 #渋谷java で発表した「あなたとスレッドダンプ」です。 スレッドダンプの使いみち、取り方、読み方について説明しています。 スレッドダンプこわくない。
Javaのスレッドダンプ、ヒープダンプの取り方 - Qiita
JavaでFullGCが頻発したり、メモリリークしてたり、busyなスレッドに埋め尽くされそうになったとき、調査に必要なダンプを取得してから再起動することはよくあるでしょう。それらの取り方。 Javaのスレッドダンプを取得する - Qiita [キータ] 前にスレッドダンプだけ書いたけど、ヒープダンプもあったほうが良いのでまとめ JavaのプロセスID取得 $ $JAVA_HOME/bin/jps -v 12345 Application -XX:OnOutOfMemoryError=/us… 67890 Bootstrap -Djava.util.logging.config.file=/us…
Thread Pools - 2.9.x
You are viewing the documentation for the 2.9.x release series. The latest stable release series is 3.0.x. Search Home Working with Play Common topics Configuration §Understanding Play thread pools Play Framework is, from the bottom up, an asynchronous web framework. Thread pools in Play are tuned to use fewer threads than in traditional web frameworks, since IO in play-core never blocks. Because
Goroutine Synchronization : D-7 <altijd in beweging>
（以下はgo 1.2.x時点での話です。将来的に仕様がかわるかどうかはわかりません） これを読んでいて、こういうの気にしてない人多いんだろうなーと思って、書いてみます。元のポストはdeferの挙動について語っているように見受けられるけれども、これは要は複数スレッドで実行されるコードについて、プログラム終了時に同期とか取りたくない、という話だと思ったので、このポストのdeferを正しく動かすには…というところからどういう形でgoroutine同士で同期を取る方法があるのか、一例を書き出していきます。 TL;DR; goでいくらgoroutineが気軽にかけるからと言って、複数スレッドで処理が行われているので同期はキチンとやらないとダメですよ。 deferの基本 goではLLのノリでコードを書けるのが売りの一つですが、メモリ管理はしてくれるものの、様々なリソース解放も全て自動というわけではあり
Java の ExecutorService の使い方 - Java 入門
Java の ExecutorService でスレッドプールを利用できる ここで説明するのは、おそらくもっとも安全にマルチスレッドプログラムを書く方法です。 さらに同様の方法で簡単に拡張することで、複数のスレッドを効率よく使うスレッドプール (Thread Pool) を利用できますので、 ぜひ覚えておきたい方法です。 その方法とは、 ExecutorService を利用することです。 ExecutorService では、 「Java のマルチスレッド・プログラミングの基本」 でみたように Thread オブジェクトをそのまま生では使いません。 ExecutorService ではスレッドプールが用意されるので、そこにタスクがディスパッチされることで処理が行われます。 Java のタスクの状態 Executor によって処理されるタスクの状態は次の四つです。 created (作成さ
[Java]ExecutorServiceの正しい終了(shutdown)の仕方 | 大発見 | 大発見
photo credit: Juan Antonio Capó ExecutorServiceを使うと簡単にマルチスレッド処理が行えますが、 終了もshutdownメソッドを呼ぶだけと思っていませんか？ shutdownメソッドだけだと不十分です。 学校の先生と生徒の関係で説明します。 shutdownメソッドは指示するだけ 学校で先生が生徒に対して、「問題が解けたら教えてねー」と言います。 生徒は問題が解けた人から「先生できたー！！」と言ってきます。 全員問題が解けた段階で授業が終わるとしましょう。 対応はこう。 先生: ExecutorService 生徒: ExecutorService内のスレッド 問題: ExecutorService.executeに渡すタスク(Runnable) 授業: mainスレッド 学校: Javaプロセス 「問題が解けたら教えてねー」
Executorを使おう - かとじゅんの技術日誌
Java5からスレッドプールが利用できるようになりました。 スレッド作成の欠点 これまでのスレッドは、ThreadクラスやRunnableクラスを組み合わせ使っていました。しかし、スレッドをただ単に使うだけだと以下のような欠点があります。 スレッドを生成から破棄までのライフサイクルで発生するコスト 一般的にはスレッド作成はOSやJVMに負荷が発生します。リクエストが頻繁で軽い場合は相当量のリソースを消費してしまいます。 リソースの消費 アクティブなスレッドはメモリを消費します。実行状態のスレッドが利用可能なCPUの数より多いとスレッドが停滞します。さらにアイドル状態のスレッドが多くなるとメモリ消費量が増えて、ガベージコレクタの負担が増大。多くのスレッドがCPUの時間を奪い合うレースコンディションになり性能も低下します。このようにCPUの数以上スレッドが存在しても意味がありません。 安定性が
スローダウン、ハングを一発解決 スレッドダンプはトラブルシューティングの味方 #wlstudy
スローダウン、ハングを一発解決 スレッドダンプはトラブルシューティングの味方 #wlstudy1 of 53
Tomcatの最大使用可能スレッド数の見積 - 銀の鍵 (The Silver Key)
我等が働き者、Tomcat。君は一体、どの程度まで多くのスレッドを作成してリクエストをさばく事が出来るんだい？ まず最初にLinuxのスレッドライブラリについて軽く言及しておかねばなるまい。Linuxのスレッドライブラリには二種類ある。 まず、昨今のLinux（Kernel 2.6及びそれ以降）で用いられているNTPL（Native POSIX Thread Library）。これは1:1モデルのスレッドライブラリで、スレッドをプロセスとして実装してある。SolarisなどではいわゆるLWP(Light Weight Process)をしてスレッドを実装してあるのだけれども、Linuxではスレッドもプロセスも同じtask_struct構造体として扱い、COE（Context Of Execution、実行コンテキスト）をそれぞれ用に割り当てて用いているようだ。各プロセスは独立した仮想メモリ
【真夏の夜のミステリー】Tomcatを殺したのは誰だ？
2007/xx/xx xx:28:50 org.apache.tomcat.util.threads.ThreadPool logFull 致命的: すべてのスレッド (200) が現在稼働中で待機しています。maxThreads (200) を増やすか、そのサーブレットのステータスをチェックしてください これは、Tomcatの持つスレッドプールが最大スレッド数に達してしまったという内容のメッセージだ。Tomcatは、スレッドの生成／破棄のオーバヘッドを削減するため、スレッドプーリングの機能を持っている。スレッドの数が多過ぎるとサーバ上のリソースを消費し過ぎてしまうため、プールには上限値として最大スレッド数を設定できる。 ■Tomcat解剖 それでは、最大スレッド数に達した場合にはどうなってしまうのか。それを理解するためには、Tomcat内部の動作に関する知識が必要となる。図3はTomca
＠IT：低負荷なのにCPU使用率が100％
今回のワンポイント アプリケーション・サーバ上でアプリケーションを稼働中に、大きな負荷がかかっていないにもかかわらず、CPUの使用率が100％になってしまうときがある。こんなときに役立つのは、スレッドダンプだ。スレッドダンプは、実行中のスレッドスタックを取得できるため、そのとき何が起きているのかを解析するには最適である。スレッドダンプの結果、原因は、java.ioパッケージ内のクラスの使い方による問題であることが判明した。これは、一般にも多く作成されているであろうダウンロードやアップロード処理で見掛けるコードの一部でもある。今回は、トラブル発生時の原因究明に役立つスレッドダンプの解説と、問題の原因となったjava.ioパッケージの使い方が引き起こす、非常に特定しにくい事象について紹介する。 低負荷なのに、CPU使用率100％ アプリケーションに大きな負荷をかけていないのに、突然CPU使用率
Java – スレッドダンプの取り方 – yusuke.blog
→その1 / スレッドダンプの取り方 ・その2 / Linux だと java プロセスがいっぱい！？ ・その3 / Windows サービスとして登録している場合は？ ・その4 / WebLogic Server とスレッドダンプ ・スレッドダンプの読み方 その1 – VM 内部スレッドと main スレッド スレッドダンプの取得方法、解析方法について網羅的に説明した資料はあまりないのでちょっと書いてみました。まとまったら侍のドキュメントに追加するつもりです。 スレッドダンプとは、 Java のプロセス内部で動作している各スレッドがそれぞれ何をしているか確認できるものです。 Java のプログラムがフリーズした場合や、パフォーマンス低下が見られる場合などに取得すると、どのスレッドが停滞しているのか、プログラム中具体的にどこで止まっているのかを解析できます。 スレッドダンプは任意のタイミン
ThreadとHashMapに潜む無限回廊は実に面白い？ (1/3) - ＠IT
ThreadとHashMapに潜む無限回廊は実に面白い？：現場から学ぶWebアプリ開発のトラブルハック（10）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） マルチスレッドのトラブルハックはさっぱり分からない… 対処が難しいトラブルといえば、GC（ガベージ・コレクション）とマルチスレッド処理に起因することが多い。 前々回（「肥え続けるTomcatと胃を痛めるトラブルハッカー 」）と前回（「JavaのGC頻度に惑わされた年末年始の苦いメモリ」）の2回にわたってGC、特にメモリ周りのトラブルを取り上げた。そこで今回は、マルチスレッド処理のトラブルの1つ、「レースコンディション（競合状態）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java 暗号化拡張機能 JDK5.0