IBM DeveloperIBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
Javaバイトコードの読み方 - プログラマーの脳みそ
Javaのデバッグをしていて、ステップ実行中にステップインを繰り返したらソースコードのないところに行き当たったことがあるだろう。あるいはEclipseでF3キーでクラスやメソッド・フィールドの宣言元を辿っていってソースコードのないところに行き当たったことがあるだろう。 Eclipseの場合、"Class File Editor"というものが開く。そこにはJavaのバイトコードのニーモニックがズラズラと並んでいて、「これは読めないや、ワケが分からない」と投げ出してしまったりしていないだろうか。 怖がることはない。ちょっとコツを掴めばすぐに読めるようになる。 Class File Editorの開き方 自前のJavaクラスの場合、ビルドして出来上がったclassファイルを開く必要がある。"Package Explorer"だとclassファイルは隠されていて見えないのでWindow -> Sh
今度はServletContext＋UUIDで負荷分散状況を調べてみた #appengine - スティルハウスの書庫の書庫
@higayasuoさんのつぶやき： #appengine でリクエストを処理するスレッドは1インスタンスあたり1つという仮定は正しい。ただし、インスタンスの特定にRuntimeのhashCodeを使うのは間違いでFilterなどで起動時にServletContextにUUIDなどを突っ込んで調べるのが正しい#appengine でJavaのRuntimeは多くのアプリケーションで共有されていて同じアプリケーションの複数インスタンスで共有されることもあるなるほど、、そこで今度は、Runtime.getRuntime().hashCode()の代わりに、ServletContextにUUIDを入れて識別する方法でTask Queueのコンテナインスタンス単位の負荷分散状況を調べてみました。こんなコードをサーブレットに書いて、ランダムIDを取得します。 final ServletContext
ITアーキテクトに求められる「Javaの互換性やサポート」という視点
Javaにおける開発環境の進歩と同時に、ブラックボックス化とそれにともなう課題も発生している。開発現場での課題解決を図る連載第1回では、互換性とサポート期限に焦点を当てる。 Javaにおける開発環境は急速に進歩しており、現場では次のような課題が発生している。すなわち「IDEすなわち統合開発環境の活用により順調にプログラムは完成したが、デバッグ段階においてJava VMに起因する問題に遭遇しJavaを取り巻く環境のブラックボックス化が進んだため、いかにして問題を解決すべきか分からない」といったものである。このような声に応えるため、本連載では次の課題を中心に、ブラックボックス化されたJava環境について解説する。 コンパイラの互換性 JavaVMのバージョンとサポート期間 JavaVMのメモリとGCの特性 Full GCの問題 文字コード変換の影響 マルチスレッドアクセスの配慮 性能問題の原因
開発者が知っておくべきJavaと仮想マシンの歴史
Javaの黎明（れいめい）期、多くの人々にJavaが知られ、広まった理由の1つは、WebブラウザにJava VMが組み込まれたことにあるでしょう。その当時のWebブラウザ開発のエキサイティングな様子は、雑誌『Wired』の古い記事「The Java Saga」で読むことができます。 Webブラウザ上で動作するJavaアプレットの勢いも借りて、各OSベンダが米サン・マイクロシステムズからライセンス提供を受け、各OSプラットフォーム用のJava環境が続々とリリースされます。 その一方、米マイクロソフトのWebブラウザ「Internet Explorer」（以下、IE）にJava VMが組み込まれたことは、歓迎とともに混乱を招きました。米マイクロソフトが提供したWindows 95／NT用のJava VM（(MSJVM)）が持つ「J/Direct」機能は高性能ながら、Win32 APIを直接呼び
Hotspot VMの基本構造を理解する
J2EEがミッションクリティカルな分野に適用されるようになり、Javaのパフォーマンスチューニングの重要性はさらに高まっています。パフォーマンスチューニングにはさまざまなパラメータがありますが、中でもJava VMに関連するチューニングの効果は大きいといわれています。本稿は、Java VMに関連するチューニング手法を学ぶための前提知識を提供することを目的にしています（編集部）。 Java VMに関連するチューニングを行い、J2EEアプリケーションのパフォーマンスを上げるためには、Java VMについて詳しく知る必要があります。本稿は2回に渡ってJava VMの基本構造と動作原理を詳細に解説しますが、内容を理解するためにはプログラムがコンピュータ上で動作する基本原理とJava VMの基本用語を知っている必要があります。Java VMの基本用語に関しては、「実行スピードに挑戦するJavaアーキ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Togetter - まとめ「javaのクラスローダ同時多発TLのまとめ」