知って使えるJVMの概要とヒープダンプ取得から解析まで
本連載では、Javaプログラムの実行を担うJava仮想マシン（JVM）について、その情報を取得するさまざまなツールの利用を通じて理解を深めます。JVMやそのツールに関する知識はアプリケーションが正常に動作しているときではなく、障害など異常が起こった際に大いに活躍します。それだけでなく、Javaプログラムを動作させる仕組みを知ることはソフトウェアを開発するエンジニアの皆さんの知的な部分を刺激するとともに、シニアレベルのJavaエンジニアへと進む第一歩となります。連載第1回はJVMの概要を解説し、模擬的なトラブルシュート体験としてヒープダンプを取得して解析します。 はじめに 今後もアプリケーションをJavaで開発、運用していくことを前提にすると、そうした業務に携わる方は次のようなことを学び続けるでしょう。 Javaの半年ごとのバージョンアップに追随して新機能などを学ぶ アーキテクチャなどでの新
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
Head toward Java 13 and Java 14 #jjug
9. 353:ReimplementtheLegacySocketAPI 重要度：★☆☆ SocketAPI( java.net.Socket や java.net.ServerSocket )の内 部実装が変わった 旧実装は -Djdk.net.usePlainSocketImpl を指定すれば使用可能 -Xlog:class+load=level を設定してどのクラスがinstantiateさ れるか見てみると変更箇所がわかる java.net.PlainSocketImpl から sun.nio.ch.NioSocketImpl に変更されてる 旧実装はレガシーなSPI(SupportProviderInterface)機構のJavaとCの実 装で、スレッドスタックをI/Oバッファとして利用したり、非同期処理を nativeなデータ構造で行っていたりと移植性等が好ましくなかった 今後
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
概要 Webアプリケーションの開発や保守をしていると、いろいろなバグに遭遇します。メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ等々、バグは様々です。こういったバグは、実際にコードを書いて、実行・再現させてツールで解析してみると理解が深まります。 ということで、いろいろなバグを実装したWebアプリケーションをつくってみました。現時点では、以下を簡単に再現できます。 メモリリーク (Javaヒープ領域) メモリリーク (Permanent領域) メモリリーク (Cヒープ領域) デッドロック (Java) デッドロック (SQL) 完了しないプロセスの待機 無限ループ リダイレクトループ JVMクラッシュ ネットワークソケットリーク データベースコネクションリーク ファイルディスクリプタリーク XSS SQLインジェクション ExceptionInInitializerErr
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
Java8のHotSpotVMからPermanent領域が消えた理由とその影響 | ギークを目指して
今回も前回の記事につづき、Java8による変更点で未だあまり紹介されていないポイントを記事にしようと思う。 今回はJava8のHotSpotVMの話。Java8ではJEP122が取り込まれ、VMのメモリモデルが変更された。JEP122のタイトル「Remove the Permanent Generation」から想像できるとおり、Java8のHotSpotVMからは従来のPermanent領域が無くなった。 なぜ、こういった変更が行われたのだろうか？また、元々Permanent領域に格納されていた情報は何処にいってしまったのか？JVM付属のツールにどういった影響があるのか？ 今回の記事ではこの点をまとめていこうと思う。 なお、HotSpotVMのメモリモデルについて詳しくない方は、先にこちらの項番（「補足 – HotSpotVMのメモリ構造概説）を読んでいただくとスムーズに読み進められるだ
Javaトラブルに備えよう #jjug_ccc #ccc_h2
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXk
非同期ストリーム処理の標準化を目指す "Reactive Streams" とは - Okapies' Archive
TL でこんなのが流れてたので少し調べてみた。 Learn about the Reactive Streams initiative & how we're supporting a standard for asynch stream processing on the JVM http://t.co/5wUF0PjTBe— Twitter Engineering (@TwitterEng) 2014, 4月 17 Reactive Streams って？ Reactive Streams ”JVM 上でのノンブロッキングなバックプレッシャーを持つ非同期ストリーム処理の標準の提案”（公式サイトより）。 ざっくり言うと、既にある JVM ベースの様々な非同期ストリーム処理フレームワーク実装の共通部分を括りだして API 化、SPI 化しようというもの。最終的には JSR での標準化を目指
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaが最強JVM言語になる日はくるのか / Will Java become strongest JVM language
GraalVM 20.0: TomcatがWindowsのネイティブイメージとして実行可能に
Javaの現状：世界で最も人気のあるプログラミング言語の一つであるJavaの動向とデータ
JVMの比較を目的とする新しいパフォーマンスベンチマーク”Renaissance”
Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide
JVM! JVM! JVM!
