コンテナ環境でのJavaトラブルシューティング
JavaScript における VM の高速化手法
この記事は、JavaScript で Flash Player の実現を頑張った（もしくは現在進行系で頑張っている）人たちの集う Flash Advent Calendar 2020 に参加しております。 皆さん、JavaScript で VM を実装する経験をお持ちでしょうか？私は過去に Java VM と ActionScript VM を JavaScript で実装したことがあります。Flash Player において VM は最も重い場所になることが多く、ここの高速化は Engine 全体の性能に大きく寄与します。この記事では、私が Pex.js にて導入し、素晴らしい成果をあげた VM の高速化手法をご紹介しましょう。 とはいえ今更 ActionScript の VM の話をされても困ると思うので、この記事では簡単な Java VM のサブセットをターゲットにして説明をします。
TOMCAT殺害事件 - Qiita
OOMKillerの殺意 顧客EC2のTomcatがアクセスの無い早朝にもかかわらずOOMKillerに突然殺されてしまったので、調査した顛末をたぶん同じような問題に直面されている方もおられるかと思いますので備忘録として記載します。 Javaヒープのチューニングにも多少役立つかと思います。 （この記事はJava8が対象となります。） OOMKillerとはOut of Memory時に、サーバ全体を守るためにメモリーを消費しているプロセスを停止するLinuxの標準機能です。 そのOOMKillerになんとTomcatが突然殺害されてしまいました。 問答無用の辻斬り状態です。 早朝ですのでアクセスログには何も記録されておらず、catalina.outには OpenJDK 64-Bit Server VM warning: Setting LargePageSizeInBytes has no
jstack でスレッドダンプを取る - にょきにょきブログ
jstack というツールがある。このツールは、現在実行中の Java プロセスのスレッドの状態を取得出来るツールだ。 思ったように性能が出ない時やデッドロックっぽい現象が発生した際はこのツールを使ってスレッドの状態を取得、つまりスレッドダンプを得て、そこから解決の糸口を探す。 今回のサンプルコードは下記コード。 少し長いが、Thread1 と Thread2 クラスはほぼ同一だ。違うのは、リソースをロックする順序。Thread1 クラスは resource1, resource2 の順にロックするが、Thread2 クラスは resource2, resource1 の順にロックする。つまり、これら２つのクラスを同時に実行するとデッドロックを起こす。 public class DeadLockTest { public static Object resource1 = new Obje
イマドキのIDE事情(79) Java VMの監視/障害解析に役立つツール
トラブルの発生時に利用するツール システム開発の現場では予期しないトラブルが付き物だ。Javaの場合、ヒープメモリやGCに関するトラブルが発生することが多い。この場合、GCログやヒープダンプを解析することで原因の特定を試みることになる。今回はこれらのトラブルが発生した場合に役立つツールを紹介する。 JDK標準ツール「jconsole」 jconsoleはJDKに標準で付属するJMXクライアントツールで、Java VMのリソースの利用状況を監視するのによく利用される。JDKインストールディレクトリのbinディレクトリ配下のjconsole.exeで起動することができ、ローカルで動作しているプロセスのほか、リモートで動作しているJava VMに接続することも可能だ。JDKのインストールディレクトリ直下のbinディレクトリにあるjconsole.exe(Windowsの場合)で起動することができ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://blogs.oracle.com/javamagazine/post/understanding-java-method-invocation-with-invokedynamic
JVM Tutorial - Java Virtual Machine Architecture Explained for Beginners
