Java|株式会社シンメトリック公式ブログ - 携帯開発から生まれる技術情報| 携帯サイト開発から生まれる技術情報ブログ

JavaベースのWebアプリケーション実行環境Tomcatをターゲットとしたアプリケーションを開発していたときのこと。一部のロジックをmainメソッドから実行できるように変更した。そして、いざ実行してみるとこれまで読み込めていたプロパティファイルが読めなくなってしまった！

なぜこんなことになってしまったのか？原因はよくある単純ミスだったけど、よくよく調べてみると衝撃的な事実を知ることに・・・。

Javaで記述されたJavaScriptの実装「Rhino」。シンメトリック社内の勉強会（檜山研）の１つ「JavaScript」チームでは、JavaScriptの学習にRhino（GUIで操作できるRhino JavaScript Debugger）を使っています。

講師の檜山さんが、Rhinoについての解説のなかで「RhinoはJavaScriptの処理系だけども、全てJavaで記述されているからJavaのクラスを使うこともできる」とコメントしていました。 RhinoでJavaのクラスを使った短いコードを試してみたりもし、そのときは正直「へ～」と感心する程度の認識だったのですが・・・。その後、しばらくしてRhinoでJavaクラスを使うことが実に手軽で便利と思うことがありました。今回はその使い方について説明します。

前回と前々回でOutOfMemoryErrorの典型的な発生パターンを３つ紹介した。

（A）サイズオーバー型

巨大な領域確保によって一気にヒープの最大サイズをオーバー

（B）メモリリーク型

開放されないオブジェクトが溜まり続けることで使用中メモリが徐々に増加し、メモリが枯渇

（C）マルチスレッド型

長時間処理により”死んだ”スレッドがメモリを食い尽くす

じゃあOutOfMemoryErrorが発生したときに、どのパターンのエラーに該当するのか？これを見抜くための手がかりを最後の話題にしたい。

前回に引き続き、OutOfMemoryErrorの話題。前回は、OutOfMemoryErrorを3パターンに分けた。

（A）サイズオーバー型

巨大な領域確保によって一気にヒープの最大サイズをオーバー

（B）メモリリーク型

開放されないオブジェクトが溜まり続けることで使用中メモリが徐々に増加し、メモリが枯渇

（C）マルチスレッド型

長時間処理により”死んだ”スレッドがメモリを食い尽くす

今回は（C)マルチスレッド型に関連するOutOfMemoryErrorを紹介する。

Javaアプリケーションサーバーを使っていると、OutOfMemoryErrorに遭遇することが時々ある。最近はサーバーの物理メモリサイズが2GBを超えることもあるのに、やっぱりこのエラーは発生する。

OutOfMemoryErrorは文字通り、メモリが足りないという意味だ。だけど、当然ながら物理メモリを増設する必要があるというわけではない（本当にそうするしかない場合もあるけど・・・）。通常はサーバーチューニングやアプリケーションロジックの見直しでこのエラーに対処する。

今回はそのうち、アプリケーション側の原因によって発生したOutOfMemoryErrorをターゲットとし、アプリケーションの見直しにより対処する方法について話したいと思う。

どんなプログラム言語でもそうなのですが、マルチスレッド下でプログラムを組むときは、シングルスレッドとは違うところに色々気を使わないといけません。 今回は、Javaマルチスレッドプログラムでは基本的なことですが(自分だけかもしれませんが)よく忘れて、不可解な動作に首を傾げてしまうポイントについて説明していきます。

弊社製品ラウンドアバウトが先日正式リリースされた。僕はラウンドアバウトの開発メンバーだったから、やっと完成したという大きな達成感がある。

しかし、その開発期間を思い起こしてみると、C言語特有の問題に直面し、実に苦労すること多かった。ラウンドアバウトはApacheモジュールなので開発言語はC言語となる。C言語で書くと実行速度が速くなるメリットもあるけど、文字列の概念がなかったり、ポインタによるアドレス指定が必要だったりと、プログラミングに注意が必要となる箇所も多い。

その内の一つがラウンドアバウトのキャッシュ機能を開発していた時に発見した不具合だ。ほとんどの画像ファイルは正しくキャッシュされるが、一部のファイルだけキャッシュされないという現象が発生。重要な機能だし、何が何でも解決しなければならない・・・。

あれこれ調べた挙句、特定の画像のみ、NULL文字に起因して発生する現象だと分かった。

今回は以前JavaでWebアプリケーションを開発した際に遭遇したJavaMailに関しての対応策とその原因の調査結果を書きます。 対策は簡単だったのですが、原因は調査するにつれ込み入った話であることが分かりました。

前回は、DateFormatクラスがマルチスレッド問題によってバグを引き起こす例を紹介した。マルチスレッドによる問題に対処するには、スレッドごとにインスタンスを作成するか、synchronizedブロックによる同期化を行う。でも「正しい同期化」を行うには十分な知識とコードの把握が不可欠・・・。

そんな時に重宝するのが、Java標準で用意されている同期化オブジェクト。どんなケースにも対応できるわけではないけど、お手軽かつ必要十分な機能を備えている。これを使わない手はない。

現在のJavaでは資源の節約があまり意識されなくなってきていますが、 今でも少ない資源(メモリ・CPU・VRAM等のリソース)の下でJavaを使ったプログラムのニーズはあります。 例えば、今では誰もが持っている携帯電話や家電製品等の組み込み系がそれに当たります。 ここでは、携帯電話でのJavaアプリケーションを例にとって、リソースが少ない環境下で、以前に私が行ったJavaとは言いがたいドケチ・プログラミングの一例を紹介します。