タグ

2011年9月27日のブックマーク (5件)

  • ThreadとHashMapに潜む無限回廊は実に面白い?

    USER PID LWP %CPU NLWP %MEM VSZ RSS TTY STAT START TIME COMMAND ……(中略)…… tomcat 13701 13779 13.9 114 1.7 745108 37344 pts/0 Rl+ 14:11 0:04 java …… ……(中略)…… tomcat 13701 13799 10.8 114 1.7 745108 37344 pts/0 Rl+ 14:11 0:03 java …… ……(中略)…… tomcat 13701 13815 10.1 114 1.7 745108 37344 pts/0 Rl+ 14:11 0:03 java …… ……(以下略)…… CPU使用率が高いプロセスのLWPIDを上から3つ抜き出すと、「13779」「13799」「13815」となった。スレッドダンプでのnidは、16進数にな

    ThreadとHashMapに潜む無限回廊は実に面白い?
    elenoi
    elenoi 2011/09/27
  • 【真夏の夜のミステリー】Tomcatを殺したのは誰だ? (1/3) - @IT

    【真夏の夜のミステリー】Tomcatを殺したのは誰だ?:現場から学ぶWebアプリ開発のトラブルハック(6)(1/3 ページ) 連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。(編集部) 【第1章】Tomcatが無応答!? トラフィックの多い大規模サイトでは、その負荷のためにさまざまな問題が発生する。それらの問題を回避するには、性能を考慮して作られたアプリケーションや、ノウハウに基づいたミドルウェアのチューニングが必要となる。 TomcatはServletコンテナとしての長い歴史を持ち、多くの採用実績を持つオープンソースのアプリケーションサーバ(以下、APサーバ)だ。大規模なサイトで採用される事例も出てきており、To

    【真夏の夜のミステリー】Tomcatを殺したのは誰だ? (1/3) - @IT
    elenoi
    elenoi 2011/09/27
    いつかつかうかねえ
  • アプリケーションサーバ/コンテナ活用編・クラスローダの仕組みを知る

    Java仮想マシンの配下では、多くのクラスが複雑に(かつ密接に)絡み合い、Javaアプリケーションの動作を支えています。しかし、複数のアプリケーションを利用しているうちに、相互のアプリケーション間で、同名でバージョンだけが異なるクラス(ライブラリ)が必要になったとしたらどうなるでしょう? しかも、そのクラスライブラリには、バージョン間の上位/下位互換性がないとしたら、どうしたらよいでしょうか。 このように、バージョンアップしなければアプリケーションBが動かない、バージョンアップすればアプリケーションAが正常に動かなくなってしまうというケースは、多くのアプリケーションが並存するサーバ上においては、大いにあり得ることです。 そこで、Tomcatのようなコンテナでは、複数のクラスローダに階層関係を持たせることで、個々のクラス(ライブラリ)の独立性を保証しています。クラスローダとは、その名のとおり

    アプリケーションサーバ/コンテナ活用編・クラスローダの仕組みを知る
    elenoi
    elenoi 2011/09/27
    くっそー
  • Javaバイトコード

    クラスファイルを説明するときに残した宿題、Code属性で定義されるバイトコードについて、ここで説明していきます。バイトコードは、JVMを前提にした一種の機械語です。javapでは、アセンブラー風に出力していますが、実際は命令を表わす1バイトのオプコードに0バイトから数バイトのオペランドで構成されています。オプコードは1バイト(もちろん符号なしです)なので、最大でも256個の命令セットしか表現できません。これが大きいか小さいかは議論があるかもしれませんが、ともかく現状で256個の内、231個は既に使用されています。(当は仮押えも含むので、指定済みと言った方が正確かも知れませんが) (1) バイトコードの特長 Javaバイトコードには、様々な特長がありますが、まずその名前に現れているように、バイト・ストリームとして扱うことができるという点です。先頭のオプコードが1バイトで表現されており、

  • 優秀な社員が、無能な管理職になる瞬間 - 知っておきたい「ピーターの法則」 - Feel Like A Fallinstar

    最近、すっかり組織をどう作るかとか5年後どんな仕組みにするかとか、そんなことを考えていたりいなかったりします。 その中で、1つ常に意識しているものに「ピーターの法則」なんてものがあるので、せっかくなので紹介がてらにブログで書いてみようかな、と。 優秀なプレイヤーと、優秀な上司はまったくの別物 どの組織でもそうなのかは分かりませんが、出世したり責任を任されたりする人というのは大体何かしら「過去の貢献・成果」を評価されています。 たとえば、 いいプログラムを書いた人が開発の責任者になったり 成績抜群の営業マンが、営業部門の新規開拓の主任になったり 実績を出したコンサルタントが、マネージャーになったり そんな感じではないかなと。 でも、そうやった起用(抜擢)が自動的にうまく行くほど甘くは無いのが組織のうっとうしいところ。 なぜなら、(たとえば3つ目の例で言うと)「優秀なコンサルタント(プレイヤー