OutOfMemoryError の調べ方 - Qiita
Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも Java がどうやってメモリを管理しているのかを知る。 しかし、実際調べてみたら予想通りというかなんというか、量が多くなってしまった。 なので、個々の用語の説明は末尾の 用語集 に押し込めたので、ここではざっくりとした概要だけ記載する。 メモリの構造 超ざっくりとした、メモリ構造を表した図。 おおきく、ヒープ（Heap）領域とネイティブ（Native）領域の２つの領域がある。 ヒープは Java プログラムが使う領域で、プログラム上で生成したオブジェクトは、このヒープ領域に配置される。 一方、ネイティブ領域は JVM が動くのに必要
Android Studio 2.0のInstant Runの仕組みを解読する - Qiita
これは、DroidKaigi 2016のセッション「Instant Runを実現する仕組み」と連動するエントリです。セッションは30分という短い時間で行われるので、細かい説明はこちらでまとめていきます。 Part I: Instant Runを理解するためのAndroidビルド概説 はじめに 2015年11月に、Android Studio 2.0 previewと同時に公開されたInstant Runは、開発中のアプリケーションのAndroidデバイスあるいはエミュレーター（以下"target"）へのデプロイメントを高速化して、また実行中のアプリケーションを再起動することなくコードを置き換えることを可能にして、デバッグ開始までの待ち時間を劇的に減らすことが可能になりました。開発者がIDE上でデバッグを指示してから、実際のデバッグ開始まで、場合によっては1秒程度で出来てしまう、というもので
恐怖の JVM 大量メモリ消費！メモリリークの謎を追え！！ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、ミドルウェア開発チームの青木(@a_o_k_i_n_g)です。将来の夢は川口浩探検隊に入ることです。 先日、弊社のアプリケーションサーバーで大量にメモリを消費するという現象に遭遇しました。アクセス頻度の低いサーバーがメモリを大量消費するという謎深いものでした。 発生当初の状況はこんな感じです。 アプリケーションサーバーでは Jetty が稼働 現象が発生した JVM は 5GB 程度のメモリを消費しており、明らかに通常ではない量のメモリを消費している 複数台のサーバーで発生していたが、全てで発生したわけではない。 また、発生したサーバーはいずれもアクセス頻度が少ないサーバーだった。 ヒープ、パーマネント、スタック ひとまず、JVM でトラブルが発生した時は何はともあれヒープダンプとスレッドダンプを見るに限ります。各種情報の取得をインフラ部隊へ依頼し、得られたヒープを解析すると、
Java: 本番環境でのデバッグスキルを磨く - ワザノバ | wazanova
https://www.youtube.com/watch?v=7KS4L-mA_-c 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Takipi のFounderであるTalWeissのSan Francisco Java User Groupミートアップでの講演。本番環境で役に立つデバッグテクニックの紹介です。 1. スレッド名の活用 スレッド名はmutable（EJB除く）である。コードのコンテキストにあわせて、Thread.currentThread().setName(Context, TID, Params, Time,...);のようにすれば、トランザクションID、Serveletパラメータ、キューメッセージID、起動時間など、スタックトレースに役に立つ情報を表示できるようになる。 J
［CEDEC 2013］性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関
［CEDEC 2013］性能はまちまちで挙動も大違い。Androidスマートフォン向けグラフィックスエンジン開発に立ちはだかった難関 ライター：米田 聡 いまや有力なゲームプラットフォームに成長したスマートフォン。ゲームデベロッパ各社は，スマートフォン上で動作するゲーム開発に取り組んでおり，CEDEC 2013でもそれをテーマにしたエンジニアリングセッションがいくつか組まれている。 左から，トライエース研究開発部の永野和博氏，大嶋貴史氏，デイビス・エリオット氏 最先端のスマートフォンは，家庭用ゲーム機に迫るグラフィックス性能を持っているが，その性能を引き出したゲーム開発には，いろいろと難しいところがあるようだ。「CEDEC 2013」の2日めとなる22日に開かれた「モバイルGPUでのハイエンドレンダリングエンジン開発事例」というセッションでは，スマートフォン向けグラフィックスエンジン開発の
Googleが開発したJavaデバッグを簡単にする新技術「cofoja」 | エンタープライズ | マイコミジャーナル
Java Programming Language Googleの20%プロジェクトからJava向けの新しい技術「cofoja (Contracts for Java)」が公開された。既存の実装に大きく手を加えることなく、デバッグをより簡単にしてくれる効果が期待できる。バグは些細なコードが起こすものだったりするが、それを追跡して発見するのは時に困難を極める。これは問題が発生した箇所と、実際にバグがある箇所が大きく離れていることが理由になっていることもある。問題発生箇所とバグ発生箇所を近くにまとめることができれば、それだけバグ発見も取り組みやすくなる。 cofojaはこれを簡単に実現するための技術。インタフェースに制約表現を追加可能にするところがポイントとなっており、クラスの実装に手を加えなくてもインタフェースに制約表記を追加することで実行時にチェックできるようになる。ブログに掲載されている
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST APIを使った開発のお供に。クライアントソフトウェアまとめ
