知って使えるJVMの概要とヒープダンプ取得から解析まで
本連載では、Javaプログラムの実行を担うJava仮想マシン（JVM）について、その情報を取得するさまざまなツールの利用を通じて理解を深めます。JVMやそのツールに関する知識はアプリケーションが正常に動作しているときではなく、障害など異常が起こった際に大いに活躍します。それだけでなく、Javaプログラムを動作させる仕組みを知ることはソフトウェアを開発するエンジニアの皆さんの知的な部分を刺激するとともに、シニアレベルのJavaエンジニアへと進む第一歩となります。連載第1回はJVMの概要を解説し、模擬的なトラブルシュート体験としてヒープダンプを取得して解析します。 はじめに 今後もアプリケーションをJavaで開発、運用していくことを前提にすると、そうした業務に携わる方は次のようなことを学び続けるでしょう。 Javaの半年ごとのバージョンアップに追随して新機能などを学ぶ アーキテクチャなどでの新
Javaの現状：世界で最も人気のあるプログラミング言語の一つであるJavaの動向とデータ
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
退屈なことはGroovyにやらせよう | Recruit Tech Blog
はじめに エンジニアの @eiryu と申します。 突然ですが、皆さんは Groovy というプログラミング言語はご存じでしょうか？JVM言語の1つであり、Javaの豊富なライブラリが使え、動的言語でもあるためちょっとしたスクリプトやツールを作るには便利です。 この記事では、実際に私が業務で作ったGroovyスクリプトについて紹介していきたいと思います。 環境情報 この記事の内容は以下の環境にて確認しています。 $ groovy -v Groovy Version: 2.5.0 JVM: 1.8.0_181 Vendor: Azul Systems, Inc. OS: Mac OS X $ awslogs --version awslogs 0.10.0 業務で実際に使った例 awslogsを使ってCloudWatch Logsから並列でログを取得する @GrabConfig(system
Rust製JVMを作成した話
rchaser53noMacBook-Pro:rj rchaser53$ javap -v java/io/PrintStream Classfile jar:file:/Library/Java/JavaVirtualMachines/jdk1.8.0_144.jdk/Contents/Home/jre/lib/rt.jar!/java/io/PrintStream.class Last modified 2017/07/21; size 9048 bytes MD5 checksum f62b2b102171bb9cd2cefa5efcf0e487 Compiled from "PrintStream.java" public class java.io.PrintStream extends java.io.FilterOutputStream implements java.lan
JVMのヒープサイズとコンテナ時代のチューニング | Folioscope
最近 JVM のヒープ領域とパラメータ、そしてコンテナの関係について調べてました。 案外まとまった情報が少なかったので簡単にまとめました。 Java のヒープサイズを設定 まずは Java のヒープサイズについて簡単なおさらいです。 本番環境で Java アプリケーションを運用する上で、JVM のヒープサイズを決定するのは非常に大事なポイントです。 ヒープ領域の最大サイズを大きくすればガベージコレクション (GC) の回数は減らすことができますが、 必要以上に大きくしすぎると無駄にリソースを消費したり、OOM killer で OS にプロセスを終了させられます。 JVM が使用できるヒープサイズは、Java API の Runtime.getRuntime().maxMemory() で確認できます。 また java の起動オプションに -XX:+PrintFlagsFinal オプショ
Java's new Z Garbage Collector (ZGC) is very exciting
Java 11 has recently been feature frozen and contains some really great features, one in particular we’d like to highlight. The release contains a brand new Garbage Collector, ZGC, which is being developed by Oracle that promises very low pause times on multi-terabyte heaps. In this article we’ll cover the motivation for a new GC, a technical overview and some of the really exciting possibilities
JVMアプリケーションを運用する際のメジャーどころチューニングポイントメモ - yoskhdia’s diary
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
JDK9のモジュールとjlinkでアプリ配布向けのJVMを作る - Qiita
JavaOne2017を前にして、待望のJava9が遂にリリースしましたね！ さて、Java9といえばやはり気になるのはjigsawによるモジュール機能です。モジュールの使い方までは良く見ますが、jlinkが個人的には気になってたので試した結果をまとめました。 はじめに Jigsawに関してですが少なくとも現時点では、fat-jarやgo言語のようなシングルバイナリを代替するようなことは単独ではできません。 ただ、モジュールとjlinkを使うことでアプリケーションを含んだ配布用のJVMを生成することが可能で、今回はそれについての説明になります。 モジュールで公開範囲の改善や依存の早期発見ができるようになったことは特に触れないので、その辺はこの記事とかを参考にされると良いと思います。 コードの準備 まずは、コードの準備です。 下記のような感じでアプリからライブラリが三階層で呼ばれてるようなサ
メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解する - Qiita
メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解するJavaバグ脆弱性トラブルシューティングjconsole 概要 Webアプリケーションの開発や保守をしていると、いろいろなバグに遭遇します。メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ等々、バグは様々です。こういったバグは、実際にコードを書いて、実行・再現させてツールで解析してみると理解が深まります。 ということで、いろいろなバグを実装したWebアプリケーションをつくってみました。現時点では、以下を簡単に再現できます。 メモリリーク (Javaヒープ領域) メモリリーク (Permanent領域) メモリリーク (Cヒープ領域) デッドロック (Java) デッドロック (SQL) 完了しないプロセスの待機 無限ループ リダイレクトループ JVM
Tomcat/Javaで対話的にデータサイエンスする
はじめに Scutumではベイジアンネットワークをはじめ、データサイエンスを積極的に導入して高性能のWAFを実現することを目指しています。データサイエンスやデータマイニングでは、解析対象のデータに対して対話的に解析を行うことが多くなります。今回は基本的には「対話的プログラミング環境でない」Javaで、データを対話的に解析する方法をご紹介します。 一般的なJavaアプリケーションのライフサイクル JavaはRに代表されるような対話的なプログラミング環境とは異なり、基本的には一度コードを書いたらそれがコンパイルされ、ある程度「固定」されたものになり、プロセス起動中は「事前に準備したコード」を使って処理をします。 Javaでデータを解析する場合には、プロセスの起動後にデータが読み込まれ、解析処理が行われ、何かしらの結果をはき出して終了する、というのが1つのステップになります。 解析を実際に行う人
Java 起動(Launcher)の仕組み - unnamed
※：この記事は下書き中に本文ががっつり消えたため、知らずに部分的に端折ってるところがあるかもしれません。(´；ω；`) Java、すなわち JVM (HotSpot) を立ち上げた時、どういった処理が行われているのでしょうか。正確に知りたい場合は OpenJDK のソースコードを読むのが最も確実ですが、概要レベルでどのような処理が行われていて、それがソースコードのどのあたりに書かれているのか案内があった方がすんなりと理解できます。と言うわけで、自分用のメモ書きをちょっとだけ整理してここで公開してみます。 なお、自分の理解をベースに記述しているので間違いが含まれている可能性があります。見つけた場合はそっとコメントか @sugarlife にお教え頂けると大変喜びます。 Java の動作概要について Java、特に HotSpot の動作概要については、OpenJDK コミュニティによって「H
「Javaの鉱脈」でJVMオプションの記事を書きました | さにあらず
WEB+DB PRESS の Vol.82 に、かなり気合いの入った JVM オプションの記事を書いたので、是非読んで頂きたい。 2014/8/23 発売ですので、既に購入頂いてる方も多いと思います。 電子書籍版もありますので物理的な媒体に興味がない方は PDF を買って下さい。 WEB+DB PRESS Vol.82@Gihyo Digital Publishing今回の記事における対象読者について#今回の記事は、ターゲットとして Java に余り時間をコミットしていないけども便利なので JVM 上で動くアプリケーションをウッカリ運用している人をイメージしながら書きました。 例えば、OSS ものだと Hadoop や ZooKeeper、Lucene や Solr、商用製品だと Stash とか JIRA とか confluence とかそういうものですね。 僕の観測範囲だと、PHP や
Gilt: Playフレームワークの活用 - ワザノバ | wazanova
https://www.youtube.com/watch?v=WliXLG2Yo5k 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約3時間前 GiltにおいてPlayフレームワークをどのように活用しているのか、Giancarlo Silverstrinが紹介してくれています。 単一のRailsアプリからマイクロサービスに切り替える過程で、JVM + Java -> JVM + Scalaと開発基盤を変遷。現在、本番環境には、250+サービス。 マイクロサービスへの展開時には、バックエンドのRailsアプリは残すかたちで既存の資産の有効活用。webレイヤでには75+個のアプリ（コード約7万行）がある。リソースとUIテーストを共有したアプリの組み合わせで、Giltのサイトは構成されている。 フラッシュセール（毎
Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか？また、元々Permanent領域に格納されていた情報は何処にいってしまったのか？JVM付属のツールにどういった影響があるのか？ 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番（「補足 – HotSpotVMのメモリ構造概説）を読んでいただくとスムーズに読み進められるだ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaが最強JVM言語になる日はくるのか / Will Java become strongest JVM language
GraalVM 20.0: TomcatがWindowsのネイティブイメージとして実行可能に
Head toward Java 13 and Java 14 #jjug
JVMの比較を目的とする新しいパフォーマンスベンチマーク”Renaissance”
サーバレスコンピューティングでJVMがよい選択である理由: John Chapin氏がQCon NYでAWS Lambdaについて考察した
Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide