マイナンバーのシステム開発の現場 2019～2020（ザード＠） - カクヨムマイナ保険証などというふざけた話が出てくる以前の話です 開発していたのは保険組合がアクセスして使うマイナンバーのシステムです 作中では以下のような話がでてきます ・入場時に守秘義務契約をSES企業の営業が代筆した ・受注者が元請けに説明せず勝手にニアショア開発にした ・システムはJava製なのだが実際に手を動かすプログラマーの大半がC系言語の経験しかない ・「スプリント形式」による開発 執筆を決意したのはそもそも自分が守秘義務契約にサインしていないことを思い出したからです
ざっくりわかった気になるモダンGC入門 - Cybozu Inside Out | サイボウズエンジニアのブログ
どうも！@yokotaso です！ 2018/05/26のJJUG CCC 2018で「ざっくりわかった気になるモダンGC入門」というタイトルで登壇させていただきました。 現在開発中の新しいGCアルゴリズムをざっくり理解することをテーマに発表しました。 発表練習用に作ったカンペの内容を公開します。ブックマークコメントでもツイートでも感想を書いていただけると喜びます！ 発表資料は、speakerdeck にあります。はじまり〜はじまり〜 はじめに 今日はざっくりわかった気になるモダンGC入門というお話をさせていただきます。 現在開発中のGCアルゴリズムの全体像を理解してもらうことを目的としたセッションです。よろしくおねがいします。 さて今日のアジェンダですが、まず簡単にこれまでのGCを復習した後に新しいGCが必要になってきた背景について少し話します。 次にShenandoahGC、ZGC、E
Java ZGC の変遷と設定オプション - A Memorandum
ZGC の変遷 ZGC オプション ZGC の変遷 JDK JEP 備考 JDK 11 JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) Linux/x64 向け JDK 13 JEP 351: ZGC: Uncommit Unused Memory (Experimental) 未使用ヒープをOSに返却 JDK 14 JEP 364: ZGC on macOS (Experimental) macOS 向け JDK 14 JEP 365: ZGC on Windows (Experimental) Windows 向け JDK 15 JEP 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) 正式リリース JDK 21 JE
Javaのメモリ管理とガベージコレクションの仕組みについて - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ■ はじめに 初めにGarbageCollectionとい言葉について。 garbage（ガベージ） ： 「ごみ」や「くず」、「がらくた」などのこと。 collection（コレクション） ：「収集」や「回収」、「収集物」などのこと。 garbage + collection = GarbageCollection （ガベージコレクション） つまりガベージコレクションは直訳でごみの収集 といった意味合いになります。 Javaでいうガベージコレクションとはプログラムで使用していないメモリを開放することです。 またガベージコレクタというもの
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
Java開発の性能改善！ その１ jstatによるヒープ/GCの確認 - Qiita
JavaのWeb開発の開発後期になると性能試験や負荷試験を実施することになると思いますが、 そのフェーズになると色々な問題が起こることが多い。 今まで起きた問題と調査・解決方法をいくつかの回に分けて紹介しようと思います。 まずはメモリリーク。 長時間サーバを起動して運用していたり、負荷試験を実施するとメモリリークを起こすことがある。 ガベージコレクションのおさらい Javaのヒープは大きくnew領域(young領域)とold領域に分かれます。 new領域には生成されてすぐのオブジェクトが格納されてマイナーGCにて未使用になった際に開放されます。 マイナーGCを何度も繰り返されても開放されない(長く参照されている)オブジェクトは old領域へと移動され、こちらはメジャーGC(フルGC)で開放されます。(メジャーGCはnewとperm領域も開放。) もう少し細かく説明すると・・・ new領域は
jstatを使うとJVMのメモリ使用状況が分かる - $shibayu36->blog;
最近頻繁に手元で起動したsbtがjava.lang.OutOfMemoryError: Metaspaceで死ぬので、メモリ使用状況を確認するコマンドを調べた。備忘録として残しておく。 jstatを使用したJavaアプリのメモリ計測 - Qiita Java開発の性能改善！ その１ jstatによるヒープ/GCの確認 - Qiita の記事が参考になる。 jpsとjstatを利用する。この二つはJDKに含まれているのでインストールされていれば利用可能。 まずjpsでJVMが動いているプロセスを特定する。 $ jps -v 60820 Main 55060 sbt-launch.jar -Xms1024m -Xmx1024m -XX:ReservedCodeCacheSize=128m -XX:MaxMetaspaceSize=256m 76790 Main 1067 -Xms128m -X
MySQL Connector/J (JDBC ドライバ)の罠まとめ - ~saiya/hatenablog
MySQL JDBC ドライバ(MySQL Connector/J)、Java で MySQL といえばまずコレだが、これまた地味に罠が多い(そして多くの人が踏んで苦しむ)のでまとめてみた。 (2015/03/19) こちら のコメント欄でご指摘ただいた wait_timeout の件について記事修正いたしました。 Summary 以下、いずれもプログラム設計時に理解しておかないと、開発中は大丈夫そうでも実用した途端に苦しまされれてしかも設計から治す羽目になる要注意な罠である: SELECT 結果は全部メモリに載ってしまう (デフォルト設定で) 大量 SELECT する場合は FetchSize, ResultSetType を要設定 利用時には制約があるので、設計段階から考慮しなければならない (後述) idle 時間の「合計で」コネクションが切られる 前回のクエリ処理から一定時間以上経
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java8でサポートしているTLS Cipher Suiteの比較調査 - Qiita
JavaアプリケーションをElastic APMで計測してみる - Qiita