実践的なJavaアプリケーションサーバの構築・運用

実践的なJavaアプリケーションサーバの構築・運用
―転ばぬ先の杖―
製品・保守事業推進本部
ミドルウェア技術サポート部
山田 貴裕
2015/04/08
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
免責事項
• Oracle と Java は、Oracle Corporation およびその子会社・
関連会社の米国およびその他の国における登録商標です。
文中の社名・商品名などは、各社の商標または登録商標である
場合があります。
• 本資料に掲載の内容は、予告なく変更されることがあります。
また、本資料を使用したことにより被った直接的・間接的な
損害などについて、いかなる責任も負いかねます。
• 本資料の再配布および無断転載を固くお断りします。
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
自己紹介
• 伊藤忠テクノソリューションズ株式会社(CTC)所属
– Javaをベースとしたミドルウェア製品の構築・サポート
• 大規模案件にも従事し、設計や構築を担当
• Oracle ACE (Middleware & SOA)
– ミドルウェア分野では日本で実質的に一人
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
会社情報 : 会社概要
2015年4月1日現在
会
社
名
(略称 CTC)
英 文 社 名
本社所在地
〒100-6080 東京都千代田区霞が関3-2-5 霞が関ビル
TEL 03-6203-5000 (代)
URL http://www.ctc-g.co.jp/
代
者
代表取締役社長
立
1972年 (昭和47年) 4月1日
表
創
菊地 哲
資
本
金
21,763百万円
社
員
数
3,919名 (CTCグループ 7,960名、2014年4月1日現在)
事 業 内 容
コンピュータ・ネットワークシステムの販売・保守、ソフトウェア受託開発、
情報処理サービス、科学・工学系情報サービス、サポート、その他
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
会社情報 : CTCの組織体制
お客様の様々なご要望にお応えできる組織体制です。
5
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
国内トップレベルの実績と経験
長年のオラクルとのパートナーシップ
20年を超える販売パートナー
上位レベルであるPlatinumレベルを継続
幅広い製品・業種での導入実績・技術力
30製品10業種においてオラクルのパートナー公認制度「Specialization」認定を取得
国内での認定数第1位 (2014年7月時点)
国内トップレベルの認定資格者数
認定資格者 : 認定技術者数で国内トップレベル
• ORACLE MASTER Platinum、ORACLE MASTER Gold 315名在籍 (2014年9月時点)
数多くの表彰
Global受賞
Oracle Excellence Award Specialized Partner of the Year 2014
Server & Storage Systems [Global] 受賞
Oracle Excellence Award Specialized Partner of the Year 2014
Server & Storage 受賞
Oracle Excellence Award Specialized Partner of the Year 2014
最多3部門受賞
Middleware 受賞
Oracle Excellence Award Specialized Partner of the Year 2014
6
Specialization 受賞
Platinum of the Year 2014 受賞
Oracle Certification Award 2014
全部門受賞
★Oracle Certified Expert, RAC
★Oracle Certified Expert, Exadata
★Oracle Certified Java Programmer, SE7
★Oracle Master Platinum Oracle DB 11g
(累計取得者数、単年取得者数)
★Oracle Master Oracle DB 12c
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
弊社の強みの一つ - WebLogic
日本BEAシステムズ時代
1998年にBEAがWebLogic社を買収する以前より、CTC社内で製品評価を実施
BEA WebLogic Server のリリース初期より代理店として販売・保守を実施
日本BEAシステムズとCTCの共著による運用ガイド本を出版
日本オラクル時代
2008年、オラクルによるBEA買収に伴い、Oracle Fusion Middleware の基盤を担う製品、
Oracle WebLogic Server としてリブランド
引き続き、日本オラクルの代理店として販売、保守サービスを継続
日本オラクルとCTCの共著による運用ガイド本を出版 (2010年12月)
WebLogic Server 12c (12.1.1) ベータプログラム参加
WebLogic Server 12c (12.1.2) ベータプログラム参加
提案・構築・保守ともに豊富な実績
【Certified Advantage Partner】を受賞し、Oracle社から最上位パートナーに認定
【Advanced Certified Support Partner】を受賞し、Oracle社からハイレベル
なサポートの提供を認められたパートナー
豊富な実績に基づくナレッジDBの保有とWebによるノウハウ情報をご提供
Oracle Award 2011, 2014
Middleware Award受賞
2014
Oracle Excellence Award
Specialized Partner of the Year
Middleware
受賞
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
前提条件
• 基本的にアプリケーションサーバ製品の種類に依存しない内容
ですが、一部製品でしか利用できないこともあります。
• HotSpot JDK/JVMおよびLinuxをベースとして説明しますが、
他のJDK/JVMやプラットフォームにも応用できる内容です。
• 本資料は、以前JJUG CCCで発表した内容を、2015年4月初め
時点の情報で加筆修正し、再構成したものです。
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
今回の範囲
アプリケーション
アプリケーションサーバ
Webサーバ
JVM
DBサーバ
コンテナ・OS
H/W
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
アプリケーションサーバの特性
• 長時間の実行
• 複数ユーザからの同時アクセス
• アプリケーションとインフラの中間
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
アジェンダ
• ログ管理
• 監視・統計
• チューニング
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
ログ管理
• トラブルシューティングの基本
• ログをきちんと出力・取得していないシステムは、
スピードメーターが壊れている車両と同じ
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
ログの種類
デフォルト
出力有無
種類
説明
用途
サーバログ
製品固有の情報を記録
運用監視
障害解析
○
アクセスログ
HTTPアクセスの情報を記録
稼働統計
障害解析
監査証跡
△
(製品依存)
GCログ
JVMのGC情報を記録
稼働統計
障害解析
×
標準出力・エラー出力ログ 標準出力・エラー出力を記録
運用監視
障害解析
△
(製品依存)
クラッシュログ
障害解析
△
(クラッシュ時)
クラッシュ時に出力
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
サーバログ
• 製品固有のログ
– 製品としての障害解析には最も利用
• 多くの場合、起動時のログも必要
– ログレベルは、通常INFO以上にすべき
• 監視にも利用
• 詳細情報を出力する場合にはDEBUG
– スレッド名・スレッドIDの出力
• 同一スレッドの処理に着目
• アプリケーションのログと突合せ
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
アクセスログ
• HTTP/HTTPS経由のアクセスを出力
• デフォルトで無効になっている製品もあるが有効化すべき
– Webサーバとアプリケーションサーバのどちら側の問題か判別
– 所要時間も出力するよう設定
• セキュリティ・監査目的でも利用
– 不正アクセス・大量アクセスの調査
– 操作履歴のトレース
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
GCログ
GCチューニング、メモリリークやOutOfMemoryError(OOME)分析に必須
オプション
-verbose:gc
-Xloggc:{file}
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCCause
-XX:+UseGCLogFileRotation
説明
GC情報を出力(基本)
GC情報を指定されたファイルに出力
タイムスタンプ(日時)を出力
6u3までは -XX:+PrintGCTimeStamps(起動時からの
経過時間)のみ
GCの詳細情報を出力
GCの発生原因を出力 (7u40以降、8でデフォルト有効)
GCログのローテーションを有効化 (7u2・6u34以降)
-XX:NumberOfGCLogFiles={n}
-XX:GCLogFileSize={size} も指定
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
GCログの解析例 - GCViewer
chewiebug/GCViewer · GitHub
https://github.com/chewiebug/GCViewer/
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
GCログ運用時の注意点
• GCログの上書きに注意
– 再起動前に退避
– e.g. -Xloggc:gc-`date +%Y%m%d_%H%M%S`.log
• JDK 8・7u76以降では -Xloggc:gc-%p-%t.log
• OSコマンドでの強制ローテーションは、大抵正常動作せず
– e.g. logrotateによるcopytruncate
– ファイルポジションが戻らず、先頭がNUL文字になるだけ
– JDK 8u20・7u76以降では外部からローテーション可能
• jcmd {PID} GC.rotate_log
• -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles={n}
-XX:GCLogFileSize={size} オプションも併せて指定
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
[参考] ヒープ詳細解析に必要な情報
• 簡易的にはヒストグラムを定期的に取得して比較
– jmap -histo:live {PID}
– jcmd {PID} GC.class_histogram (7u4以降)
負荷:中
• ヒープダンプは、最低2回取得して差分を解析
– 通常時
• jmap -dump:live,format=b,file={file} {PID}
• jcmd {PID} GC.heap_dump {file} (7u4以降)
負荷:高
– OOME発生時
• -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath={path}
• OOME発生後にはJVMとしての動作が保証されないので、必ず再起動
– 必要に応じて、-XX:OnOutOfMemoryError='kill -ABRT %p' なども併せて指定
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
標準出力・エラー出力ログ
• スレッドダンプやOOMEなど、JVM本体の出力を捕捉するため
OSレベルでリダイレクト
– スレッドダンプ(kill -3 {PID})は、以下で代用も可能
• jstack {PID}
• jcmd {PID} Thread.print (7u4以降)
– 環境によっては以下オプションを利用
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile={file}
– アプリケーションでSystem.outやSystem.errの利用を極力排除
• System.setOutやSystem.setErrを使うことで、(製品によっては設定ベースで)
別ファイルに出力するようにできるが、JVM本体の出力とは別
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
スレッドダンプの解析例 - ThreadLogic
ThreadLogic — Project Kenai
https://java.net/projects/threadlogic/
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
スレッドダンプの解析例 - 侍
侍 - ログ , スレッドダンプ解析ツール
http://samuraism.jp/samurai/
%
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
標準出力・エラー出力ログ運用時の注意点
• ローテーションにはApache付属のrotatelogsなどを利用
– java 〜 2>&1 | rotatelogs -l console.log.%Y%m%d 86400
– ログの削除は、別途検討
– GCログがローテーションできないJVMを利用している場合、
標準出力・エラー出力ログに出力し、併せてローテーション
• java 〜 >/dev/null 2>&1 は、基本的に禁止
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
クラッシュログ
• hs_err_pid{PID}.log
– デフォルトではJVM起動時のカレントディレクトリに出力
– -XX:ErrorFile={file} で出力先を指定
• JVMクラッシュする要因
– ネイティブライブラリの誤用・不具合
– JVM自体の不具合
– OOMEやStackOverFlowError
• 発生ライブラリやスタックトレースを基に既知不具合を確認
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
監視・統計
• トラブルを未然に防いだり、早期発見につなげる
• 傾向を分析し、サイジングの礎とする
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
OSリソースの監視・統計
• CPU
– 使用率、キュー長
• メモリ
– 使用量、ページング
• ネットワーク
– ソケット状況、I/O発生量
• プロセス単位の情報取得
– 上記までをプロセス単位に識別できるよう取得
• e.g. netstat -anp, ps auxww
– JVMによるCPU高負荷時にはスレッド単位のCPU使用率も取得
• e.g. top -b -H -p {PID} -n {count}, ps auxww -L
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
OSリソースの監視例 - vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----r b
swpd
free inact active
si
so
bi
bo
in
cs us sy id wa st
1 0
0 5772388 548932 888980
0
0
0
48
17
17 4 1 94 0 0
0 0
0 5770884 548932 890680
0
0
0
0
45
41 1 0 99 0 0
3 0
0 5732472 548964 928772
0
0
0
4 848 563 56 11 34 0 0
0 0
0 5770768 548928 890304
0
0
0
88 418 226 38 5 57 1 0
0 0
0 5770908 548928 890304
0
0
0
0
18
27 0 0 100 0 0
CPU割当や I/O待ちとなっているプロセス
CPU使用率
スワップイン・スワップアウトしているメモリ量
Tips: vmstatの結果と併せて日時を出力
$ vmstat 5 | awk '{print strftime("%Y-%m-%d %H:%M:%S"), $0}'
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
プロセス監視、ヘルスチェック
• プロセス監視
– OSコマンドの場合、必要なプロセスのみに限定
• ps -ef | grep java | grep -v grep | grep ~
– JDKツールの場合、対象JVMと実行ユーザが同一であることや、
/tmp/hsperfdata_{user} が実行時に削除されないように注意
• jps -mlv | grep ~
• ヘルスチェック
– 実際にリクエストを投げて応答を確認
• e.g. curl, wget
– Full GCを考慮してタイムアウトやリトライを実装
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
ログ監視・統計
• ログ
– サーバログは、ERRORレベル以上を基本的に監視
• WARNINGの監視は、大体において過剰
– サーバログだけではなく、標準出力・エラー出力ログも監視
• OOMEやStackOverFlowErrorを捕捉
• 製品によってはサーバログの重要度が高い内容も出力
– GCログやアクセスログから統計
• e.g. GC回数、平均所要時間
• e.g. HTTPステータス(1xx~5xx)ごとの件数、平均レスポンス時間
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
GC統計
• jstat
– 統計情報として取得するには有用
– GCフェーズや詳細なタイミングが不明
• 障害解析には不適切
$ jstat -gcutil -t ${PID} 10s
Timestamp
9.4
19.4
29.4
39.4
49.4
59.4
S0
0.00
99.97
99.97
72.62
0.00
0.00
S1
0.00
0.00
0.00
0.00
99.94
0.00
E
62.41
3.82
4.22
11.24
54.02
11.73
O
11.73
17.34
17.34
12.83
13.94
23.00
M
98.30
98.53
98.53
98.47
98.45
98.53
CCS
96.21
97.47
97.47
97.25
96.99
96.54
YGC
5
8
8
10
11
14
YGCT
0.112
0.163
0.163
0.211
0.232
0.329
FGC
3
3
3
4
4
5
FGCT
0.288
0.288
0.288
0.433
0.433
0.975
GCT
0.399
0.451
0.451
0.644
0.665
1.304
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
サーバリソース監視・統計
• JMXやREST APIによるリソース監視・統計
e.g.
– ヒープ使用量、GC回数
– 実行中のスレッド数、リクエストキュー長
– HTTPセッション数
– コネクションプールの使用数、空き待ち数
etc.
※現在値だけでなく、最大値も可能であれば取得
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
JMXによる監視例 - Java Mission Control
Java Mission Control
http://www.oracle.com/technetwork/jp/java/javaseproducts/mission-control/
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
JMXによる監視例 - 虚無僧
虚無僧2.0
http://samuraism.jp/komuso/
$ ./komuso.sh XXX.properties
Timestamp,HeapFreePercent,State,ExecuteThreadTotalCount,ExecuteThreadIdleCount,Stand
byThreadCount,PendingUserRequestCount,OverloadRejectedRequestsCount,StuckThreadCount
2015/03/21 23:33:01 JST,83,RUNNING,5,1,4,0,0,0
2015/03/21 23:33:02 JST,81,RUNNING,5,0,2,1,0,0
2015/03/21 23:33:03 JST,78,RUNNING,5,0,2,3,0,0
2015/03/21 23:33:04 JST,70,RUNNING,5,0,2,7,0,0
2015/03/21 23:33:05 JST,70,RUNNING,5,0,2,8,0,0
2015/03/21 23:33:06 JST,69,RUNNING,5,0,2,5,0,0
2015/03/21 23:33:07 JST,69,RUNNING,5,0,2,4,0,0
2015/03/21 23:33:08 JST,69,RUNNING,5,0,1,2,0,0
2015/03/21 23:33:09 JST,69,FAILED,5,0,1,18,5,0
2015/03/21 23:33:10 JST,69,FAILED,5,0,1,17,11,0
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
RESTライクな監視例 - Jolokia
Jolokia
http://www.jolokia.org/
$ curl "http://localhost:8080/jolokia/read/java.lang:type=Memory/HeapMemoryUsage/" | jq '.'
{
"request": {
"mbean": "java.lang:type=Memory",
"attribute": "HeapMemoryUsage",
"type": "read"
},
"value": {
"init": 62914560,
"committed": 76021760,
"max": 891289600,
"used": 43484848
},
"timestamp": 1427698609,
"status": 200
}
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
チューニング
• 限られたリソースで最大限の効果を発揮させる
• 計測し、ボトルネックを見つける
• パフォーマンス向上だけではなく、最適化する
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
サーバ分割・分散配置
• 複数プロセス、複数コンテナ・OSによって処理
– スレッド間のロック競合、アプリケーション間の影響低減
• パッチ適用・設定変更など再起動が必要な場合
– 計画的に再起動することでリークも解消
アプリケーション
アプリケーション
アプリケーションサーバ アプリケーションサーバ
JVM
JVM
コンテナ・OS
H/W
アプリケーション
アプリケーション
アプリケーションサーバ アプリケーションサーバ
JVM
JVM
コンテナ・OS
コンテナ・OS
H/W
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
OS環境設定
• 最低限行うべきもの(Unix)
– ファイルディスクリプタ(FD)
• e.g. ulimit -n 8192
• 大量のjar読込、ソケット、ファイル
• 足りない場合には lsof -n -P -p {PID} で確認
– コアファイルサイズ
• ulimit -c unlimited
• 出力場所にも注意 (/proc/sys/kernel/core_pattern)
• コアファイルは、gdbなどを利用して対象OS上で解析
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
ネットワーク関連設定
• TCPタイムアウト
– 接続開始: connectのタイムアウト
– 接続中: TCP KeepAliveによるポーリング
– 接続終了: TIME_WAITのタイムアウト
• 接続バックログ
• IPv4を優先
– 必要に応じて -Djava.net.preferIPv4Stack=true
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
JVMメモリの使われ方
アプリケーションサーバでの利用イメージ
New
リクエストで
利用
Metaspace or Perm
+ Native
Old
アプリケーション
アプリケーション HttpSession
サーバ本体で で固定的に利用 として利用
利用
アプリケーション
サーバ本体
アプリケーション
実際には計測してみないと分からないが
イメージを持つのは大事
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
JVMメモリ・GCのチューニング
• JVMメモリ
– ヒープサイズ
• 最小容量(-Xms)＝最大容量(-Xmx)
• 大きい場合、GC回数が減少・GC時間が増加
• 小さい場合、GC回数が増加・GC時間が減少
– Metaspace (JDK 8以降)
• -XX:MaxMetaspaceSize={size} で制限 (以前 -XX:MaxPermSize={size} 相当)
• 一般的なGC方式
– レスポンス重視の場合、-XX:+UseConcMarkSweepGC
– スループット重視の場合、-XX:+UseParallelOldGC
– CPU・メモリが潤沢な場合、-XX:+UseG1GC (7u4以降)
ヒープレイアウトとして、1世代・2世代を選ぶJVMもあり
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
アプリケーションサーバのよくある構造
接続プール
リクエストキュー
スレッドプール
リクエスト
実行スレッド
DB接続
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
スレッドのチューニング
• 流量制御の要であり、一般的にスレッドプールで再利用
– スレッド数は、TPS×レスポンス時間(秒)を目安
– リクエストキュー長も制限
e.g. 1秒に最大5トランザクション、レスポンス時間が平均2秒
0
1
2
3
4
5秒
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
[参考] アプリケーションのスレッドに関する注意点
• ThreadLocalは、注意して利用
– 再デプロイ時にメモリリークの原因
– 再利用前提のスレッドに紐づくため、アプリケーションで明示的に破棄
• 製品によっては再デプロイ時などに自動削除やエラー出力に対応
• スレッドの自前での作成は原則禁止
– Java EEではスレッドに紐づけて、各種リソースを管理
• e.g. トランザクション、セキュリティ
– Java EE 7ではConcurrency Utilities for EE
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
コネクションプールのチューニング
• 新規コネクションを張る際のオーバーヘッドを低減
– 基本は、初期容量＝最大容量かつスレッド数≧容量
– リソースを適切に制限することが重要
• 容量以外のポイント
– ステートメントキャッシュも利用
– ファイアウォールがある場合、
定期的にポーリング
– コネクションリークに注意
接続プール
DB
• Java SE 7のtry-with-resources構文
• 製品機能によって確認・解消
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
タイムアウトのチューニング
• Javaの特性上、実行タイムアウトを直接的に指定不可
– 以下のような部分で間接的にタイムアウトを指定
• JDBCでのSQL実行
• 外部HTTPアクセス (e.g. HttpClient)
• トランザクションタイムアウト
etc.
• システムとして全体的なタイムアウト設計も実施
– フロント＞バックエンドとなるようなタイムアウト設計が基本
• e.g. Webサーバ実行時間＞SQL文タイムアウト
– トランザクションやHTTP KeepAliveのタイムアウトでは逆
• バックエンドが先にタイムアウトしてしまうと、意図しない挙動の原因
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
まとめ
• アプリケーションサーバの特性を理解
– 長時間の実行 → ログ管理、監視・統計
– 複数ユーザからの同時アクセス → チューニング
– アプリケーションとインフラの中間 → 総合力が大事
• 古いバージョンを利用している方は、アプリケーションサーバ
だけでもバージョンアップを検討・実施
– Java SE・Java EEとも互換性を重視
– パフォーマンスの向上、より便利なツールの利用
といっても、なかなかバージョンアップできない環境も多いので…
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
Oracle Java SE Advancedについて
Oracle Java SE Advanced (サーバ環境向け) および Oracle Java SE Advanced Desktop
(デスクトップ環境向け) は、Java SEの長期サポートを提供する有償ライセンス製品です。
EOL以降も継続してアップデートリリースをご提供する他、以下のサービスやツール群を
ご利用いただけます。
Oracle Java SE Advanced
の主な内容
概要
標準オラクル・サポート
24時間365日、27言語対応の電子メール及び電話サポート
「Oracle Premier Support」へのお問い合わせサービス
アップデートリリースの提供
バグ修正、セキュリティ問題の修正などを含むアップデートリリースの提供 (EOL後も提供を継続)
Java Flight Recorder
/ Java Mission Control
障害対応を強力に支援する Java の問題解析機能
Oracle Java SE Advanced のサポート・ロードマップ
※ブラウザ経由で実行されるJavaアプリケーション (アプレットなど) の場合、期間の例外あり
Java
version
提供開始
EOL
標準サポート
終了
延長サポート
終了
無期限
サポート
Java SE 6
2006年12月
2013年2月
2015年12月
2018年12月
あり
Java SE 7
2011年7月
2015年4月
2019年7月
2022年7月
あり
Java SE 8
2014年3月
2017年3月(予)
2022年3月
2025年3月
あり
Copyright (c)2015 ITOCHU Techno-Solutions Corporation
Copyright (c)2015 ITOCHU Techno-Solutions Corporation