タグ

GCとjavaに関するshigeaki1jpのブックマーク (14)

  • JVM入門 -メモリ管理編-

    関ジャバ'19 7月度 - connpass https://kanjava.connpass.com/event/134133/ 登壇資料

    JVM入門 -メモリ管理編-
  • JavaのGCの仕組みを整理する - Qiita

    最近メモリを大量に使うJavaのプロセスに関する仕事があり、GCの知識が必要になったので調べたことをまとめておきます。調べたら色々出てくる時代ですが考えを整理するために書きました。間違った認識をしている可能性はあるのでそこはご指摘いただけると幸いです。 注: この記事は最新のGC事情を整理するものではなく、古典的?な手法について書いてます。 JVM まずはざっくりJavaの基的な仕組みから。 JavaのプロセスはJVMと呼ばれる仮想マシンの上で動作します。この仕組みは様々なOSで動作し、環境の差異を気にする事なくコンパイルされたJavaのコード(クラスファイル)を様々な環境で実行可能にしてくれます。 JVMにはいくつ種類がありますが、記事はOpen JDKで用いられるHotSpot VMの場合を想定しています。(他のJVMとの違いはわからない) ヒープ領域 Javaのプロセスを開始する

    JavaのGCの仕組みを整理する - Qiita
  • Javaパフォーマンス最後のフロンティア:ガベージコレクタの削除

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Javaパフォーマンス最後のフロンティア:ガベージコレクタの削除
  • 第5回 Java VMの情報を取得する(前編) | gihyo.jp

    Java VMで監視すべき4つのポイント 前回は、システム運用者がJava VM(JVM⁠)⁠、アプリケーションサーバ、Javaアプリケーションから、ログ、JMXとMBean、ダンプを使用して情報を取得する方法を紹介しました。今回と次回では、JVMからどのような情報を最低限取得するべきか、詳細を紹介します。 システム運用者は、JVMが滞りなくアプリケーションを支援できているか、アプリケーションが動いているかを確認する必要があります。JVMは内部で管理しているさまざまなリソースに関する情報を持っていますが、システム運用者がそれらをすべてを監視することは不可能です。そこで、たくさんある情報の中から、次の4つのポイントに絞ってJVMの動きを監視します。 JVMがアプリケーションを中断することなく実行できているか JVMがアプリケーションのリソースを奪っていないか OSのリソースが十分に割り当てら

    第5回 Java VMの情報を取得する(前編) | gihyo.jp
  • Concurrent Mark-Sweep Garbage Collection #jjug_ccc

    Re-Introduction: Concurrent Mark-Sweep Garbage Collection @ Japan JUG Conference.Read less

    Concurrent Mark-Sweep Garbage Collection #jjug_ccc
  • OutOfMemoryError の調べ方 - Qiita

    Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも Java がどうやってメモリを管理しているのかを知る。 しかし、実際調べてみたら予想通りというかなんというか、量が多くなってしまった。 なので、個々の用語の説明は末尾の 用語集 に押し込めたので、ここではざっくりとした概要だけ記載する。 メモリの構造 超ざっくりとした、メモリ構造を表した図。 おおきく、ヒープ(Heap)領域とネイティブ(Native)領域の2つの領域がある。 ヒープは Java プログラムが使う領域で、プログラム上で生成したオブジェクトは、このヒープ領域に配置される。 一方、ネイティブ領域は JVM が動くのに必要

    OutOfMemoryError の調べ方 - Qiita
  • Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6

    * 2015/12/01 12:40 修正 * P.65 の1段落目の表現を修正しました。(不要オブジェクトが閾値を上回る -> 生存オブジェクトが閾値を下回る) 表現だけ見ると内容は一緒なのですが、オプションで指定可能な閾値の意味を考慮すると修正前の文章は誤りでした。 Introduction of G1 GC at JJUG CCC 2015 Fall. http://www.java-users.jp/?page_id=2056Read less

    Garbage First Garbage Collection (G1 GC) #jjug_ccc #ccc_cd6
  • JavaVMのメモリチューニング

    システムの処理性能を高めるには,基盤となるJavaVM自体のチューニングを適切に実施する必要があります。日立のJavaVMでは,2種類のメモリ空間を管理しています。 この章では,ガーベージコレクションと日立のJavaVMでのメモリ管理,およびJavaヒープとExplicitヒープのチューニングについて説明します。 <この章の構成> 7.1 ガーベージコレクションとJavaVMのメモリ管理の概要 7.2 フルガーベージコレクション発生を抑止するためのチューニングの概要 7.3 Javaヒープのチューニング 7.4 Javaヒープ内のTenured領域のメモリサイズの見積もり 7.5 Javaヒープ内のNew領域のメモリサイズの見積もり 7.6 Javaヒープ内に一定期間存在するオブジェクトの扱いの検討 7.7 Javaヒープの最大サイズ/初期サイズの決定 7.8 Javaヒープ内のPerma

  • 「Javaパフォーマンス」はいい本だった - 愛と勇気と缶ビール

    Javaパフォーマンス 作者: Scott Oaks,アクロクエストテクノロジー株式会社,寺田佳央,牧野聡出版社/メーカー: オライリージャパン発売日: 2015/04/11メディア: 大型この商品を含むブログ (11件) を見る とても馬鹿っぽいタイトルになってしまったが、気にしないのである。 だいたいの内容としては、 パフォーマンス・チューニングに関する一般論 Java付属のモニタリングツール(jstatとかあれとかこれとか) JITコンパイル周りについて GCについて 等々がいい感じに、過不足なく書いてある。 既にJava10年選手で、GCのチューニングもしたことあるし、JVMとは戦友みたいなものだ…みたいな人にはおそらく必要ないだろうが、JVM周りのあれやらこれやらを知らない人(つまり僕のような)がとりあえずJava始めてみたときに、頭の中に見取り図を書くためにはこのを読むのが

    「Javaパフォーマンス」はいい本だった - 愛と勇気と缶ビール
  • SparkアプリケーションのためのJavaガベージコレクションのチューニングについて - TEPPEI STUDIO

    この記事は、インテルの SSG STOビッグデータテクノロジーグループのメンバーからDataBricksに寄稿されたブログを翻訳したものです。誤訳がありましたら、@teppei_tosaに御連絡ください。 Sparkは、その優れた性能、シンプルなインターフェイス、および分析や計算のための豊富なライブラリによって、幅広い業界で採用されてきています。ビッグデータエコシステムにおける多くのプロジェクトと同様に、Sparkは、Java仮想マシン(JVM)上で実行されます。Sparkはメモリに大量のデータを格納することにおいて、Javaのメモリ管理とガベージコレクション(GC)に大きく頼っています。また、プロジェクトTungstenなどの新たな取り組みは、将来のバージョンで、メモリ管理のさらなる簡素化と最適化を目指しています。しかし、今日時点でも、JavaのGCオプションとパラメータを理解しているユ

    SparkアプリケーションのためのJavaガベージコレクションのチューニングについて - TEPPEI STUDIO
  • Javaのプログラムはどうやって動いているの? GC編

    2015.04.24 JJUGナイトセミナ Javaのプログラムはどうやって動いているの? GC編Read less

    Javaのプログラムはどうやって動いているの? GC編
  • JVM! JVM! JVM!

    10. jmc Java Mission Control ● メモリ統計、スレッド数、クラス数をグラフィカルに表 示 ● jconsoleと似たような感じだけどjmcの方がなうい? ● ダッシュボードのカスタマイズ(グラフの追加)が可能 ● Flight Recorderというプロファイリングツールがあ る。が商用ライセンスが必要(らしい ● -XX:+UnlockCommercialFeatures -XX:+FlightRecorder ● Eclipseプラグインとしても利用できる(らしい

    JVM! JVM! JVM!
  • Java 7 CMS GCの基本的な情報の整理 - nekop's blog

    バッチ処理などスループット重視のアプリケーションはデフォルトのパラレルGCで良いが、Java EEアプリケーションサーバなどレスポンスタイム重視のものやHadoopなどのクラスタ系ソフトウェアで死活監視に引っ掛る系などのstop the worldをなるべく避けたいいわゆるサーバ系ソフトウェアを運用する場合には、UseConcMarkSweepGCを付与して停止時間の短いCMS GCを使う。その場合にCMSのチューニングに踏み込もうとするとなんだか難しい記述がいっぱいで若干困るので、簡単なガイドをメモとして書いておく。 対象バージョンは以下。 $ java -version java version "1.7.0_51" OpenJDK Runtime Environment (fedora-2.4.5.1.fc20-x86_64 u51-b31) OpenJDK 64-Bit Serve

    Java 7 CMS GCの基本的な情報の整理 - nekop's blog
  • 第8回 イレギュラーなヒープの動作を理解する | gihyo.jp

    Tenured領域を早く使ってしまうパターン 前回ご紹介したように、HotSpotのヒープでは、アプリケーションがオブジェクトを作成するとまずはじめにEden領域が割り当てられ、マイナーGCによってSuvivor領域、Tenured領域へと移動していく流れが一般的でした。 しかし、このパターンではないイレギュラーなパターンがいくつか存在します。 その1つが、「⁠オブジェクトが一般的なパターンに比べ、早くTenured領域に移動してしまう」というものです。 図1 Tenured領域を早く使ってしまう例 Tenured領域はメジャーGCの対象であり、メジャーGCはNew領域を対象とするマイナーGCに比べ、はるかに停止時間が長くなります。そのため、このようなパターンが頻繁に起こる場合は、メジャーGCの多発によってアプリケーションの停止時間が増加します。 図2 Tenured領域を早く使ってしまう

    第8回 イレギュラーなヒープの動作を理解する | gihyo.jp
  • 1