JavaアプリケーションサーバでThreadLocal利用時の注意点 - yamadamn’s blog
本日はJava EE Advent CalendarとJPOUG Advent Calndarの14日目です*1。 さて、先日11/9のJJUG CCCで話してきた内容で、Javaアプリケーションサーバでは、アプリケーションからThreadLocalは極力利用しない方がよいとのスライドを載せていました。 しかし、当日は時間がなく、また参考情報程度でしたので、説明を省いていました。 これについて、このエントリでは少し丁寧に説明をしたいと思います。 Javaアプリケーションサーバ 構築・運用の勘所 from Takahiro YAMADA 実は、上記スライドは、当日話した内容から以下の修正を加えています。 「極力利用しない」→「注意して利用」に変更 「再利用前提のスレッドに紐づくため、アプリで明示的に破棄」を追記 これがサマリにはなるのですが、説明していきましょう。 ThreadLocal ま
Executorsを利用してみる - happytanの足跡
JDK5から「java.lang.Thread」を直にnewしなくてもスレッドを扱えるようになりました。 Executorsクラスでは、スレッド処理に必要なクラスを生成します。ファクトリの役割を担ってくれてます。 「ExecutorService」の実装クラス、「ScheduledExecutorService」の実装クラスを生成します。 メソッド）newSingleThreadExecutor()、newFixedThreadPool(int nThreads)、newCachedThreadPool()をみてみる 「ExecutorService」の実装クラスを生成するには、3つのメソッドがあります。 No クラス名 概要 1 newSingleThreadExecutor 単一スレッドを作成する 2 newFixedThreadPool 固定数のスレッドを再利用するスレッドプールを作
マルチスレッドのコンテキスト切り替えに伴うコスト - naoyaのはてなダイアリー
また Linux カーネルの話です。 Linux では fork によるマルチプロセスと、pthread によるマルチスレッドでの並行処理を比較した場合、後者の方がコストが低く高速と言われます。「スレッドはメモリ空間を共有するので、マルチプロセスとは異なりコンテキストスイッチ時にメモリ空間の切り替えを省略できる。切り替えに伴うオーバーヘッドが少ない。」というのが FAQ の答えかと思います。 が「オーバーヘッドが少ない」と一言にいわれても具体的にどういうことなのかがイメージできません。そこで Linux のスレッド周りの実装を見て見ようじゃないか、というのが今回のテーマです。 3分でわかる(?) マルチプロセスとマルチスレッド まずはうんちく。マルチプロセスとマルチスレッドの違いの図。以前に社内で勉強会をしたときに作った資料にちょうど良いのがあったので掲載します。Pthreadsプログラミ
UNIX上でのC++ソフトウェア設計の定石 (3) - memologue
鉄則3: マルチスレッドのプログラムでのforkはやめよう マルチスレッドのプログラムで、「自スレッド以外のスレッドが存在している状態」でfork*1を行うと、さまざまな問題を引き起こす可能性があります。「問題」の典型例としては、子プロセスのデッドロックが挙げられます。問題の詳細を把握しないまま、マルチスレッドのプログラムで不用意にforkするのはやめましょう！ 何が起きるか 実例から見てみましょう。次のコードを実行すると、子プロセスは実行開始直後のdoit() 呼び出し時、高い確率でデッドロックします。 void* doit(void*) { static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; pthread_mutex_lock(&mutex); struct timespec ts = {10, 0}; nanoslee
Singletonクラスのアクセスを簡単にマルチスレッド対応させたい - krustf の雑記
Singletonクラスを作るたびにそのクラスのメンバ変数としてMutexとかを宣言したくないんです。冗長だし。 Lock, UnLockの方法もきっと面倒なんですよね。アクセスするたびにロックを手動で書くような。 そういったものを書かせないで、これまでみたいにget_instanceメソッドを呼び出してアクセスできるような形にしたい。 ということで、そんな感じの物を書いてみました。C++0x無いと動きません。GCC4.4(boost1.43.0), MSVC10(boost1.44.0)で確認しました。 （boost1.43.0はrvalue referenceに対応できてないので冗長なコードが混ざってます） ちゃんと定義しておくべきだろうなというのがいくつか欠けてる気がしますが…。 http://ideone.com/N2sFR 本当ならポリシーベースにするべきなのかな、と思ったのです
多分、こんなんでいいはず。 - krustf の雑記
先日書いた記事 - Singletonクラスのアクセスを簡単にマルチスレッド対応させたい - krustf の雑記 で書きましたけど、最終的に今書いてるライブラリに追加したものです。 MSVC10, boost1.44.0で動作確認しました。 #include <utility> #include <boost/thread/mutex.hpp> // マルチスレッド // ------------------------------------------- template< class T > class multi_thread_access { public: multi_thread_access( T* ) : Lock_( SingletonMutex_ ) {}; multi_thread_access( multi_thread_access&& other ) : L
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
