2016年現在のJavaについて - arclamp
Sun MicrosystemsがOracleに買収されたのが2009年ですから、あれから7年が経ちました。 2013年、Javaは大人になったはずだった 僕は2013年に「イマドキのJavaとORACLEについて - arclamp」という記事をアップし、次のように書きました。 そんなわけで「ORACLEはJavaにコミットしているのか？」という質問が無意味なぐらい、ORACLEはJava技術だけではなく、Javaユーザーの方を向いているのです。 もちろん、ORACLEは（SUNに比べて）イノベーションが足りないとかスピード感がないとか批判もできるのですが、これだけエンタープライズのユーザーが増えた中では、Javaの後方互換性を保ちつつ、着実に進化していく、つまりは引き続き安心してJavaを使うことができるというのは大きな価値でしょう。 そう、Javaは本当の意味でオトナになったのかもし
Getting "Unable to open socket file" message when executing jstack / jmap / jcmd and unable to generate a thread dump / heap dump - Red Hat Customer Portal
Issue Got the following "Unable to open socket file: target process not responding or HotSpot VM not loaded" when executing jstack command and unable to generate a thread dump: [root@myhost /tmp]# jstack -l <JAVA_PID> <JAVA_PID>: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding Got the following "
Tomcat-8.5.0を試す - R42日記
Tomcat-8.5.0-betaがリリースされています。 リリースノートによると、 The Apache Tomcat Project is proud to announce the release of version 8.5.0 of Apache Tomcat. Apache Tomcat 8.5.0 is intended to replace 8.0.x and includes new features pulled forward from Tomcat 9.0.x. The minimum Java version and implemented specification versions remain unchanged. The notable changes compared to 8.0.x include: Added support for HTTP/2,
JVMとGCのしくみ - ITエンジニアとして生きる
先日職場でJVMの話をしてた。 ちょうどいい機会だからちょっとまとめたいと思う。 JVMの構成まずはJVMの構成について。JVMには３つの領域が存在する。 Permanent領域（非ヒープ領域） New領域（ヒープ領域） Old領域（ヒープ領域） Permanent領域にはJVMにロードされたクラスやメソッドの情報、New領域にはインスタンス化されたオブジェクトの情報、Old領域には寿命の長いオブジェクトの情報が管理される。（「寿命の長い」については後述のScavenge GCを参照。） Permanent領域は非ヒープ領域、New領域とOld領域はヒープ領域となる。 非ヒープ領域には基本的にGCは走らず、JVM起動時に静的な情報が管理される。（※） 一方、ヒープ領域はインスタンス化されたオブジェクト情報といった動的な情報が管理され、GC対象となる。 ※ユーザ定義のクラスローダーが存在する
Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか？また、元々Permanent領域に格納されていた情報は何処にいってしまったのか？JVM付属のツールにどういった影響があるのか？ 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番（「補足 – HotSpotVMのメモリ構造概説）を読んでいただくとスムーズに読み進められるだ
OutOfMemoryError の調べ方 - Qiita
Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも Java がどうやってメモリを管理しているのかを知る。 しかし、実際調べてみたら予想通りというかなんというか、量が多くなってしまった。 なので、個々の用語の説明は末尾の 用語集 に押し込めたので、ここではざっくりとした概要だけ記載する。 メモリの構造 超ざっくりとした、メモリ構造を表した図。 おおきく、ヒープ（Heap）領域とネイティブ（Native）領域の２つの領域がある。 ヒープは Java プログラムが使う領域で、プログラム上で生成したオブジェクトは、このヒープ領域に配置される。 一方、ネイティブ領域は JVM が動くのに必要
jcmd が "well-known file is not secure" という IO 例外を上げてくるときの対処 - tokuhirom's blog
jcmd が "well-known file is not secure" という IO 例外を上げてくるときの対処 jcmd が "well-known file is not secure" などと意味不明なことを申した場合、この例外は 以下の位置から上がっている。 JNIEXPORT void JNICALL Java_sun_tools_attach_LinuxVirtualMachine_checkPermissions (JNIEnv *env, jclass cls, jstring path) { jboolean isCopy; const char* p = GetStringPlatformChars(env, path, &isCopy); if (p != NULL) { struct stat64 sb; uid_t uid, gid; int res; /*
Java言語コードでのリークの診断
Java言語コード内のリークの診断は難しい可能性があります。通常、アプリケーションの非常に詳しい知識が必要です。さらに、プロセスが反復し、冗長なことがよくあります。この項では、Java言語コード内のメモリー・リークを診断するために使用できるツールについて説明します。 注: この項で説明したツールに加えて、数多くのサードパーティ・メモリー・デバッガ・ツールが利用可能です。メモリー・デバッグ機能を備えた商用ツールの例として、Eclipse Memory Analyzer Tool (MAT)とYourKit (www.yourkit.com)の2つがあります。他にも数多くありますが、推奨される特定の製品はありません。 Java言語コードのリークの診断に使用される2つのユーティリティを次に示します。 NetBeansプロファイラ: NetBeansプロファイラは、メモリー・リークの場所をすばやく
AttachNotSupportedException due to missing java_pid file in Attach API
Building a profiler of my own, I use the JVMTI API to build a native library agent. This agent can be started together with the JVM by using the addition parameter -agentlib. In addition there is the Attach API which allows to inject an agent into a running JVM. I wanted to implement this feature to my profiler using the following code: try { String pid = VirtualMachine.list().get(0).id(); Virtual
[tips][Java]OpenJDK8付属ツール実行時エラーの対策 - Akira's Tech Notes
Table of Contents 1. プロセスのアタッチ出来ない 2. Metadata does not appear to be polymorphic 3. unknown CollectedHeap type 本記事のOpenJDK障害は次の環境で確認しています。 $ java -version openjdk version "1.8.0_60" OpenJDK Runtime Environment (build 1.8.0_60-b24) OpenJDK 64-Bit Server VM (build 25.60-b23, mixed mode) $ uname -a Linux mimi 4.1.6-1-ARCH #1 SMP PREEMPT Mon Aug 17 08:52:28 CEST 2015 x86_64 GNU/Linux 1 プロセスのアタッチ出来ない $
OutOfMemoryErrorが発生したときにきちんとJavaプロセスを殺す - nekop's blog
OutOfMemoryErrorが発生してもスレッドを異空間に葬るだけでJava VMはそのまま動き続ける場合があるけど、当然ながら状態に一貫性のない状態で動いている可能性があるわけで基本的にはとっとと死んで欲しいわけである。一般的に言うところの「不定」状態。OOMEはErrorであってふつうの例外ではなく、致命的なJava VMエラーを示すものである。OOME発生後にプロセス再起動しないでそのままどうこうしようというのは絶対に避けた方が良い。 例えばJDBCのコネクションオープンしてDBからデータを読み込んでるときにOOMEが起きた場合、JDBCコネクションは大抵オープンしっぱなしで回収はされなかったりする。OOMEではfinallyブロックが呼ばれる保証はない。JDBCコネクションリークくらいならまだ良い方だが、これは全てに当てはまる。A-B-Cといったセットになっている処理は例外など
Java開発の性能改善！ その２ GCログの解析とHeapの設定 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 第２回です。 なかなか更新できる時間がないですが マイペースで書いていこうと思います。 ストックやフォローをして頂けると励みになります。 さて前回はGCの仕組みの概要説明とjstatでのモニタリングでした。 今回はCGログの分析をしてみようと思います。 JVMのGCログ設定 まずはGCログが取得できるように設定しないと始まりませんね。 以下のようなオプションをjavaの起動コマンドに付与すると GCの情報を取れるようになります。 -verbose:gc [GC 919089K->41941K(943744K), 0.2300771 se
Web Application Server を動かす時の Java8 起動オプションのメモ - その手の平は尻もつかめるさ
一般的な Web Application Server *1 を Java8 で動かすにあたって，最近有効にしている起動オプションについてメモ． 何か間違っていたり，あるいは「こっちの方が良い」みたいなのがあれば教えて下さい． -server server mode で起動させる (指定しないと client mode になる可能性がある，マシンスペックによってスイッチする？)． -Djava.net.preferIPv4Stack=true If IPv6 is available on the operating system the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept connections from,
JavaVMのGCログ出力とGCViewerについて - TASK NOTES
JavaでOutOfMemoryErrorが発生したけど原因がわからないなどトラブル時に確認することがあるGCログについてまとめました。 Java実行時のGCログオプション GCログの出力方法で簡単なのはJava実行時に-verbose:gcオプションを指定することです。ログは標準出力に出力されます。 基本的には以下のオプションを指定するのがいいと思います。-verbose:gcと-Xloggc:<filename>を一緒に指定するとオーバーライドされるので-verbose:gcを指定する必要はありません。 オプション 内容 -Xloggc:<filename> GCイベント情報のロギング -XX:+PrintGCDetails 全てのGCで詳細メッセージの出力有効化 -XX:+PrintGCDateStamps 全てのGCで日付スタンプの出力を有効 -XX:+UseGCLogFileRo
Java 8時代の開発者のためのデバッグ／トラブル解決の基本・応用テクニック～JJUG CCC 2014 Springまとめリポート（後編）
Java 8時代の開発者のためのデバッグ／トラブル解決の基本・応用テクニック～JJUG CCC 2014 Springまとめリポート（後編）（1/3 ページ） Java開発における3大トラブルと対策、IDEのデバッガー活用の必要性、Java 8より導入された新しいメモリ領域を使いこなすためのテクニック、独自のトランザクショナルメモリ機構を実装した有効性などをお伝えする。 日本Javaユーザーグループは2014年5月18日、「JJUG Cross Community Conference 2014 Spring」を開催した。「JJUG Cross Community Conference」（以下、JJUG CCC）は毎年春と秋に開催されるカンファレンス。初心者向けからエキスパート向けまで、Java／JVMに少しでも関連すればいいという広いテーマでさまざまな講演が行われている。 前編では、「S
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JDK6の初期ヒープサイズ - 年中アイス
String.replaceAll single backslashes with double backslashes
alternatives経由でJavaを使うならjavacも指定しよう - Qiita
Javaのスレッドダンプ、ヒープダンプの取り方 - Qiita
