Javaメモリ、GCチューニングとそれにまつわるトラブル対応手順まとめ - 日記のような何か
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
JVMのオススメ起動オプション - oinume journal
なんか秘伝のタレみたいになってきたので後世のために共有。 前提 Webアプリケーションを想定 TomcatなりJettyなりがListenするポートは外部からはアクセスできない ※-Xms -Xmx -Xmn あたりは搭載しているメモリ容量によって変える、-XX:MaxPermSize -XX:PermSizeは384mあれば十分だと思うけどロードするクラスの数次第なので要調整。 NOW=`date "+%Y%m%d-%H%M%S"` JAVA_OPTS="-server -Xms2g -Xmx2g -Xmn1g -XX:MaxPermSize=384m -XX:PermSize=384m \ -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=85 -XX:MaxTenuringThreshold=32 \ Javaプログラマーなら習得しておきたい J
Javaにおける文字コードまわりの話 - あしのあしあと
毎度毎度、文字コードの話は面倒である。開発のメインストリームでないことと、外部調整が必要であることが原因だと思う*1。 プラットフォームが変わるたびに、毎回検証しているような気がする。私の場合だと、毎回OSが違う。Windows Server、AIX、HP-UX、Red Hat Linux。毎回Java仮想マシン（JVM）が違う。SunのJDK（今はOracleか）、JRockit（これもOracleか）、IBMのJVM、HPのJVM。データベースエンジンは、だいたい同じ。 本当にみんな、毎回やっているのだろうか？ とりあえず、Javaで開発することは決まっている前提で、外部設計と内部設計にて、やるべき（と思っている）ことをまとめておく。 以降で挙げる例は、次のようなシステムをイメージしている*2。 構築対象システム Webアプリケーション バッチ 外部システム ホスト 外部設計 画面や帳
MacOSのJDK6環境はデフォルトでShift JIS - Hello, world! - s21g
嫌がらせとしか思えないのですが、MacOSのJDK6は、デフォルトのエンコーディングがSJISになっています。JDK5ではUTF8だったのに、なぜ... とりあえず、デフォルトでUTF8にしたい場合は、~/.zshrc あたりで
Java用デコンパイラー·JD MOONGIFT
JDはJava製のフリーウェア。Javaはコンパイルする言語なので（コンパイルされるのは中間言語だが）、コンパイルされた内容は基本的には見られない。だが以前の担当者が作ったプログラムを修正しないといけない時に元のコードがなくなっていたら惨事になってしまう。 Java向けのデコンパイルツール そんなときに役立つのがデコンパイラーだ。コンパイルの逆、コンパイルされたコードを元のソースに戻してくれるソフトウェアだ。使い方を誤ると問題になりかねないが、使い方によってはとても役立つ。その一つがJDだ。 JDはGUI版とEclipseのプラグイン版の二つが存在する。GUI版についてはWindows/Mac OSX/Linuxそれぞれ用に実行ファイルが提供されている。使い方は簡単で、ただコンパイル済みのjar/classファイルを開けば良いだけだ。 検索ウィンドウ コードはハイライト表示され、階層も分か
Undo,Redoの実装って何十回もやってる気がする - あしあと日記
undo,redoの実装って何十回もやってる気がする。毎回同じパターンだ。undo,redoが登場するような編集ソフトは大体同じパターンに落とせる。フレームワークも作った。ブログにそういう内容を書きたいが面倒くさい。需要があれば面倒でも書くんだけどなあ http://twitter.com/youpychan/status/994486992 という発言をしたら何人か反応を頂いたので書いてみることにする。 需要があるなら書こう。undo,redoだけじゃなくてグラフィカルな編集ソフト全般の話をいつかまとめたいと思っていたので、ちょいとシリーズで書いてみようかとおもう http://twitter.com/youpychan/status/994636764 書こうと思う。 まずUndo,Redoについて。 Unod,Redoってみなさんどういう風に実装しているでしょうか？ 私はコマンドパタ
Java におけるコード進化パターン (Code Evolution Patterns in Java)
Java におけるコード進化パターン (Code Evolution Patterns in Java) asato shimotaki <asatohan at gmail.com> 最終更新日 : 2009/6/21 (2004/4/22 より) [...] For twenty years, I spent two or three hours a day looking at pairs of things -- buildings, tiles, stones, windows, carpets, figures, carvings of flowers, paths, seats, funiture, streets, paintings, fountains, doorways, arches, friezes -- comparing them, and asking my
MOONGIFT: � FTPもSCPもWebDAVも「AnyClient」:オープンソースを毎日紹介
サーバにファイル転送をする方法はいくつか存在する。もっとも知られているのはFTPだろう。そしてセキュアになったSFTPやSCP、さらに最近ではWebDAVが利用されることもある。 いくつもの手法があると、それに合わせてソフトウェアを用意する必要がある。が、それでは面倒だろう。一括して使えるのが良い。 今回紹介するフリーウェアはAnyClient、様々なプロトコルに対応したファイル転送ソフトウェアだ。 AnyClientはJavaで作られたソフトウェアで、OSを選ばずに動作する。対応しているプロトコルはFTP/S、SFTP、WebDAV/S、SSHにも対応している。認証もパスワードまたは公開鍵認証が利用できる。 画面は二画面ファイラー風で、左がローカル、右がリモートになっている。ファイルのアップロード/ダウンロード、リネーム、フォルダ作成と言った処理が可能だが、パーミッションの設定はできない
マルチスレッドプログラムのバグ (JavaWorld 2002/1)
マルチスレッドプログラムのバグ 首藤 一幸 産業技術総合研究所 グリッド研究センター 注: このページの文章は JavaWorld 誌 2002年 1月号に掲載された以下の記事の元原稿です。 JavaWorld 誌編集部の了承の元に、本ウェブページに掲載しております。 首藤一幸, "マルチスレッドプログラムに対するデバッギングの心得", 月刊ジャバワールド 2002年 1月号, pp.64-73, IDGジャパン, 2001年 11月 もくじ 序文 1. はじめに 2. レース状態 3. ロック 4. Java言語のモニタ 5. デッドロック スレッドの異常終了によるデッドロック Threadクラスのstop()とsuspend()メソッド 6. 再現性の低さ 7. 予防が肝腎 8. デバッグ assertion機能 デッドロックの検査 9. 注意一秒ケガ一生 参考文献 序文 スレッドは
The JSR-133 Cookbook
Where: Normal Loads are getfield, getstatic, array load of non-volatile fields Normal Stores are putfield, putstatic, array store of non-volatile fields Volatile Loads are getfield, getstatic of volatile fields that are accessible by multiple threads Volatile Stores are putfield, putstatic of volatile fields that are accessible by multiple threads MonitorEnters (including entry to synchronized met
Mostly-Concurrent Mark & Sweep GC のアルゴリズム
目次 1. 前置き 2. HotSpot VM 1.4.x の GC の種類 3. Mostly-concurrent Mark & Sweep 4. 応用 4.1 世代別 GC との組み合わせ 4.2 カードマーキング (Card Marking) 4.3 並列化 (Parallel GC) 4.4 ビットワイズ・スイープ (Bitwise Sweep) 4.5 インクリメンタル・コンパクション (Incremental Compaction) 5. 参考文献 脚注 コメント 1. 背景 ガーベージコレクション(GC) には色々なアルゴリズムが存在するが、大雑把に言って Stop-the-World (STW) 型 GC と On-the-fly 型 GC に大別される。 STW 型の GC はプログラムの実行中にはガーベージの回収を行わず、メモリが枯渇した時になって始めてガーベージの回
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://icedjava.blogspot.com/2007/12/evolution-of-java.html
LAPSE