私的まとめ。2段階に分かれており、今回はその初回。 JVM内の挙動を知るにはJVMに渡されるバイトコードを知ることからと考え、これについてまとめる。 バイトコードの確認 例えば public class Test { public static void main(String[] args) { Test test = new Test(); } } を $ javap -c Test すると、mainメソッドのバイトコードが public static void main(java.lang.String[]); Code: 0: new #1; //class Test 3: dup 4: invokespecial #16; //Method "":()V 7: astore_1 8: return になっていることがわかる。コンストラクタ呼び出しがnew,dup,invokesp
1.はじめに エンタープライズシステムのような大量の情報管理を行うシステムにおいては、データベースシステムは必須です。現在、データベースシステムには、リレーショナルデータベース(RDBMS)以外にも、XML データベースやオブジェクト指向データベースと選択肢も増えています。しかし、既存リソースの再利用や使い勝手、性能、製品のブランド等を考慮すると、RDBMS が選択されることが多いと思います。 Java 側のオブジェクトと、RDBMS 側のレコードを対応付けて相互に変換することを O/R マッピングと言います。Java では O/R マッピングに関する処理は、DataAccessObject (DAO) パターン [3] によって局所化し、 DAO 内で JDBC によって RDBMS にアクセスするような設計がよく使われます(図 1-1)。 JDBC を使った O/R マッピングは、単調
GCの動きを見たいときは -Xloggc: や -XX:+PrintGCDetails をつけて、GCViewer で見ていた。 これは時系列でのGCの動きや、メモリの推移を知るには便利だけど、細かい動きについては解り辛い。概要を知るには便利だけど、細かく知りたい時は不便という感じ。 # 使いこなせていないだけかもしれないけど。 GCが起きるメモリリークプログラムをさくっと書いてみる。 import java.util.List; import java.util.ArrayList; public class GCTest { public static void main(String[] args){ List<String> list = new ArrayList<String>(); for(;;){ String str = new String("hoge"); list.
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 この連載では、Javaアプリケーションのパフォーマンスチューニングについて、さまざまなテクニックやツールの使い方を紹介していきます。連載の第1回では、パフォーマンスチューニングにおける基本的ルールや、HPが提供する各種のJavaパフォーマンス・ツールの使い方を説明します。なお、今後の連載では、JVMレベルにとどまらず、OSのカーネル・パラメータやネットワーク・パラメータのレベルでのチューニング方法も解説します。また、より高度なチューニング技法として、JVMのガベージ・コレクションやスレッド競合に注目する方法も紹介する予定です。 連載予定 第1回 Javaパフォーマンスチューニングのルール 第2回 Javaのガベージ・コレクション
ヒープ領域とパーマネント領域 JavaVMには、独自のメモリー管理機構が搭載されています。不要になったオブジェクトを定期的に破棄してメモリーを開放するガベージ・コレクション機能と、永続的に使われるオブジェクトであるかどうかを判定する機能が搭載されています。 JavaVMが確保するメモリーには、大きく3つあります。オブジェクトを管理するヒープ領域と、読み込むクラス情報を確保するパーマネント領域、それ以外に、ランタイムが必要とするシステム領域です。 ヒープ領域は、必要に応じて保存と破棄が繰り返される領域となります。クラス情報は、パーマネント領域に格納されます。それ以外に確保されるメモリーとして、ランタイムが利用するシステム・メモリー(OS依存ヒープ・メモリー)とスレッド管理のメモリーが別領域になります。 New領域: ヒープ領域 New領域は、Eden、Survivor0、Survivor1(
OutOfMemoryError回避のためのJavaコーディング - 完結編|株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報| 携帯サイト開発から生まれる技術情報ブログ 前回と前々回でOutOfMemoryErrorの典型的な発生パターンを3つ紹介した。 (A)サイズオーバー型 巨大な領域確保によって一気にヒープの最大サイズをオーバー (B)メモリリーク型 開放されないオブジェクトが溜まり続けることで使用中メモリが徐々に増加し、メモリが枯渇 (C)マルチスレッド型 長時間処理により”死んだ”スレッドがメモリを食い尽くす じゃあOutOfMemoryErrorが発生したときに、どのパターンのエラーに該当するのか?これを見抜くための手がかりを最後の話題にしたい。 原因究明の手がかりは・・・? OutOfMemoryErrorの原因究明。見るべきポイントはいくつかある。
Java SE > Java SE Specifications > Java Virtual Machine Specification The Java® Virtual Machine Specification Next The Java® Virtual Machine Specification Java SE 7 Edition Tim Lindholm Frank Yellin Gilad Bracha Alex Buckley 2013-02-28 Legal Notice Table of Contents Preface to the Java SE 7 Edition Preface to the Second Edition Preface to the First Edition 1. Introduction 1.1. A Bit of History 1.2
本記事は、HP-UX Developer Edgeに掲載された記事を株式会社アットマーク・アイティおよび本記事の筆者が独自の判断のもとに加筆・修正したものです。 今回は、Javaにおけるヒープ・メモリ管理の詳細を説明します。JVMのヒープ・メモリの中で、新しいオブジェクトと古いオブジェクトがどのように配置されるかを理解することで、ヒープ・メモリが有効に利用されているか否かを判断することができます。また、JVMが出力するガベージ・コレクションのログを解析し、オプションの指定によってヒープ・メモリのサイズを適切にチューニングする方法を紹介します。 Java ヒープ・メモリの構造 Javaにおけるガベージ・コレクションのメカニズムを理解するには、まずヒープ・メモリの構造を知っておく必要があります。 図1は、JVM におけるヒープ・メモリの構造を示したものです。この図が示すように、ヒープ・メモリの
GC周りでトラブルシューティングした際の経験や、Web等で調べたことをまとめてみる。 前提 ・JVMは、Sun Javaを想定。(他は使ったことないです。。。) ・Sun Java 1.5-1.6を想定。 目標 マイナーGC、Full GCそれぞれが頻発することなく、かつそれぞれの実行時間を1秒未満に抑えること。 マイナーGCは1秒未満どころではなく、もっと短くなるべき。どれくらいが理想かは?(0.1秒未満ぐらいを目指したい?) 連続した負荷状態(想定されるピークアクセス)でもOutOfMemoryErrorが発生しないこと。 理想的な状態は、上記に加えて、Full GCの発生が低頻度であること。 具体的には、できるだけマイナーGCで短命オブジェクト(1回使ったらもう使わないようなオブジェクト。逆にセッションオブジェクト等は長命オブジェクトとなる)を破棄させて、短命オブジェクトが、Tenu
Skip to Content Oracle Technology Network Software Downloads Documentation Search Java Platform Standard Edition 7 Documentation Skip Java SE Documentation Navigation Links What's New Release Notes Tutorials and Training The Java Tutorials JavaFX 2 and Scene Builder 1 Tutorials Java Training More Information Java SE 7 Names and Versions Java SE White Papers Documentation Accessibility Specificatio
Permanent領域のチューニング JVMにはPermanent領域と呼ばれるヒープ領域があります。ここにはクラス定義やメソッド、フィールドなどのメタデータが格納されます。 Permanent領域のデフォルトのサイズは、一般的なアプリケーションにとって十分な大きさに設定されています。しかし、アプリケーションによっては非常に多くのクラスをロードするものもあり、Permanent領域が足りなくなることがあります。例えば、JSPやサーブレットを多用するアプリケーション(アプリケーションサーバなど)は、デフォルトのPermanent領域サイズでは足りなくなり、次のようなエラーが発生することがあります。 $ java ManyClassLoadingTest Permanent generation is full... increase MaxPermSize (current capacity
Webシステムの安定動作には、メモリ使用量の適切な見積もりが不可欠。だがJavaVMでメモリがどのように管理されるかを理解しているだろうか? メモリに関する問題が発生すると、知識や技術資料の不足によって問題が長期化しがち。JavaVMでどのようにメモリが管理されているかを理解し、正確なメモリサイジングやメモリ関係のトラブルの早期解決へとつなげよう。 JavaVMのメモリ構造を理解しよう まず、JavaVMがどのようにメモリを使っているかを理解しておこう。JavaVMがプログラムを実行すると、Javaのプロセスによってメモリが使用される。Javaのプロセスでは、Javaヒープ、Permヒープ、Cヒープ、およびスレッドスタックという4つのメモリ領域を使用する。 Javaヒープはアプリケーションプログラムの各種オブジェクトを格納する領域であり、Classのnewで確保される。JavaヒープはNe
J2EEがミッションクリティカルな分野に適用されるようになり、Javaのパフォーマンスチューニングの重要性はさらに高まっています。パフォーマンスチューニングにはさまざまなパラメータがありますが、中でもJava VMに関連するチューニングの効果は大きいといわれています。本稿は、Java VMに関連するチューニング手法を学ぶための前提知識を提供することを目的にしています(編集部)。 ガベージコレクション(Garbage Collection:以下GC)と聞くと、「プログラマの煩雑なメモリ管理作業を軽減してくれるのはいいけど、アプリケーションの応答時間を遅らせたり、スループットを低下させたりして、パフォーマンスの観点からは非常に困ったものだ」というイメージを持つ人も多いのではないでしょうか。 GCはJava HotSpot仮想マシン(Java HotSpot Virtual Machine:以下
サーブレットとは サーブレットは、クライアント・サイドで動くアプレットに対して、サーバー・サイドで動くプログラムです。サーブレットは、ブラウザとサーバーのインタフェースとしてよく使われるCGIに似た機能を提供します。つまり、サーブレットは単独で動作するJavaアプリケーションではありません。HTTPを解釈して、期待する応答を返すサーバーの上で動作します。 CGIで使用する言語は決まっていないので、JavaでCGIを書くこともできます。しかし、CGIをJavaで書いたものはサーブレットではありません。サーブレットはServlet APIを使っています。具体的には、上位クラスの中にjavax.servlet.Servletインタフェースがあります。 サーブレットはCGIに比べると、拡張性のあるマルチプラットフォーム名インタフェースとなっています。CGIでできることはサーブレットでもでき、次のよ
Revised: 2nd/Nov./2003; Since: 26th/Jan./2003 データ・エリア JVM のメモリ構造は、スタックとヒープに大別されます。ヒープ (Heap) は GC の対象で、JVM 起動時に割り当てられる広大な領域です。Java 仮想マシン・スタック (Java Virtual MAchine Stack) はスレッドごとに割り当てられる、メソッド起動ごとにフレーム (Frame) と呼ばれるデータを出し入れする線形のデータ構造です。クラスのインスタンスなどはヒープに格納しますが、インスタンスのような GC 対象となる動的なデータと、クラス構造などの静的なデータは、別の領域に保持し、静的な構造を保持する領域をメソッド・エリア (Method Area) と呼びます。 図:JVM のメモリ構造 Java 仮想マシン・スタック JVM はプロセスの一つとして、O
One thing to realize about our fractional reserve banking system is that, like a child's game of musical chairs, as long as the music is playing, there are no losers. Andrew Gause, Monetary Historian 「部分準備金融制度について一つだけ実現している事は、 子供の椅子取りゲームのように、 音楽が流れ続けている限りは敗者が存在しないということである。」 アンドリュー ガウス、金融史家 【Sun HotSpot VMのガベージコレクションとヒープ】 TomcatはApache Software Foundationが提供するフリーのサーブレットコンテナ実装です。要するにJ
最近Androidの開発をしていまして、例にもれずEclipseが体に合わないため(というかEmacsが好きなため?)、Emacsで開発をしています。 しかし、いままでJavaで本格的に開発したことなかったのでEmacsにおけるJavaの開発環境がまったく整備されていないので、EmacsでもうちょっとJavaの開発がしやすくする便利なモードないのかなと調べてみました。 いろいろ調べてみたら、JDEE − Java Development Environment for Emacsってのがあったのですがなんかごてごてしていて、そんなモリモリの機能いらないんだよなぁと思っていたら「ajc-java-complete」っていうのをみつけました。 ajc-java-completeは名前の通りauto-completeやyasnippetと連携して補完することをメインにしたものになっていて、今も開
Java7のクロージャの提案者の一人,Neal Gafterのブログが大変参考になるので,ちょっと野良翻訳してみよう. クロージャの定義 Java 言語にクロージャを追加しようという我々の提案に関して混乱があるようだ.そもそも,Javaにはすでに無名インナークラスという形で,クロージャがあるのではないか? すでにあるものをなぜまた追加しようというのか? 一部の人々には,我々の提案には,クロージャとは関係ないものが含まれているように思われているようだ.例えば,control invocation 構文,null型,Unreachable, 型パラメータ付きthrows,関数インターフェイス型,「非ローカル」な returnなどがそうだ.Javapolisでの講演で,なぜこれらの機能が提案に含まれているのかを,これまで不可能だったことを可能にするための実用的な観点から説明したつもりだ.しかし,
確認 その1 ちょっと Java クラスの確認。 1つの Java クラス(Groovy クラスも同じ)に、名前とシグニチャが同じインスタンス・メソッドと static メソッドを同時に定義するとコンパイル・エラーになります: // Java public class MyPojo { public static void say(){ System.out.println("Hello, STATIC world!"); } public void say(){ System.out.println("Hello, INSTANCE world!"); } } 確認 その2 Java クラス(Groovy クラスも同じ)に static メソッドが定義されているとき // Java public class MyPojo { public static void say(){ Syste
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く