なぜ Go では何百万もの Goroutine を作れるのに Java は数千のスレッドしか作れないのか?
なぜ Go では何百万もの Goroutine を作れるのに Java は数千のスレッドしか作れないのか? (この記事は Why you can have millions of Goroutines but only thousands of Java Threads の翻訳です) 経験のあるエンジニアならば JVM 言語で次のようなエラーを見たことがあるでしょう。 [error] (run-main-0) java.lang.OutOfMemoryError: unable to create native thread: [error] java.lang.OutOfMemoryError: unable to create native thread: [error] at java.base/java.lang.Thread.start0(Native Method) [erro
Why goroutines are not lightweight threads?
Processor By ColiN00B [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)]GoLang is gaining incredible popularity these days. One of the main reasons for that is the simple and lightweight concurrency in the form of goroutines and channels that it offers to the developers. Concurrency has existed since long ago in the form of Threads which are used in almost all the applications these d
Acroquest
◆ １．SolarisとJavaVMのスレッドモデル Solarisオペレーティングシステム（以下、Solaris）マルチスレッド・プロセス・アーキテクチャ とJavaVMスレッドモデルの基本的な知識をおさらいします。 ◆ ２．ネイティブスレッドからJavaスレッドを見つける方法 特定のネイティブスレッドに対応するJavaスレッドを見つける方法を紹介します。 １．SolarisとJavaVMのスレッドモデル まずこの章では、Solarisのマルチスレッド・プロセス・アーキテクチャとJavaVMのスレッドモデルについておさらいします。 網羅的な説明はそのボリューム上不可能ですので、最低限知っていなければならないことにとどめていることに注意してください。 １－１．Solarisマルチスレッド・プロセス・アーキテクチャ Solarisのスレッドモデルはカーネルレベルとユーザレベルの２段階で構成さ
Javaスレッドメモ(Hishidama's Java thread Memo)
概要 Javaでは、マルチスレッド用のクラスとしてThreadが用意されている。[2017-04-15] しかし新しいJavaでは、Threadを直接使う事はあまり無い。 ExecutorService/Future（JDK 1.5）やFork/Join（JDK 1.7）といったクラスが追加されているので、そちらを使う。 Java21で仮想スレッド（virtual thread）が導入された。[2023-09-23] これにより、従来のスレッドはプラットフォームスレッド（platform thread）と呼ぶようになった。 Javaでは、マルチスレッド用のThreadクラスが用意されている。 Threadを継承して独自のクラスを作り、runメソッドをオーバーライドして処理本体を記述する。 class スレッドクラス名 extends Thread { @Override public vo
Handling exceptions from Java ExecutorService tasks
I'm trying to use Java's ThreadPoolExecutor class to run a large number of heavy weight tasks with a fixed number of threads. Each of the tasks has many places during which it may fail due to exceptions. I've subclassed ThreadPoolExecutor and I've overridden the afterExecute method which is supposed to provide any uncaught exceptions encountered while running a task. However, I can't seem to make
スレッドプールのサイズを調整する
この他にも "サービスを受けるのを待つ人が，キューの中に立っている平均時間はどれくらいか？" といったような疑問に，Littleの法則で答をだすといった内容のゲームは，他にもたくさんあります。 図１. Littleの法則 同じようにLittleの法則は，スレッドプールサイズの決定にも使うことができます。私たちがしなければならないのは，リクエストの到着率と，サービスに必要な平均時間を測定することです。そうすれば，これらの値をLittleの法則に挿入して，システムの平均要求数が計算されます。その数値がスレッドプールのサイズよりも小さければ，その結果に従ってプールのサイズを小さくすることが可能なのです。逆に計算結果がスレッドプールのサイズよりも大きい時には，問題はもう少し複雑になります。 実行中のリクエストより待ち状態のリクエストの数が多い場合，まず最初に判断しなければならないのは，もっと大きな
Servlet 3 spec and ThreadLocal
As far as I know, Servlet 3 spec introduces asynchronous processing feature. Among other things, this will mean that the same thread can and will be reused for processing another, concurrent, HTTP request(s). This isn't revolutionary, at least for people who worked with NIO before. Anyway, this leads to another important thing: no ThreadLocal variables as a temporary storage for the request data.
Threading stories: ThreadLocal in web applications - Java Code Geeks
This week I spend reasonable time to eliminate all our ThreadLocal variables in our web applications. The reason was that they created classloader leaks and we coudn’t undeploy our applications properly anymore. Classloader leaks happen when a GC root keeps referencing an application object after the application was undeployed. If an application object is still referenced after undeploy, then the
Java EE環境における非同期プログラミング - nekop's blog
Java EE環境では基本的にスレッドの生成は許されていません。この制限はEJB仕様書に記述されており、ブループリントなど他のドキュメントにも記載されています。これらの制限はかなり古い時代に考えうる最大の制限を記述したものであり、「ファイルにアクセスしてはならない」など今となってはあまり現実的ではない記述も多くなっています。しかしながら、「スレッドを生成してはならない」というのは依然多くのコンテナに適用される現在も有効な制限であり、実際にスレッドの生成などを行うと誤動作するケースがあります。今回は、なぜこのスレッドの制限があるのか、現実的にどうすれば良いのか解説します。 コンテナは様々なものをスレッドに結びつけて管理しています。様々なものというのは例えばセキュリティ、トランザクション、データソースなどのコンテナリソースです。コードのほうがイメージしやすいでしょうから、以下に擬似コードを挙げ
JPA: Thread-safety when injecting EntityManager
When professionalism comes in to play, so don’t miss it. As I wrote in post Why we need type-level injections in JavaEE, injecting EJB 3 stateful beans into servlet instance fields is not thread-safe. Along the same line, injecting EntityManager with @PersistenceContext into servlet instance variables is not thread-safe, either. EntityManager is just not designed to be thread-safe. For example, th
Java – スレッドダンプの取り方 – yusuke.blog
→その1 / スレッドダンプの取り方 ・その2 / Linux だと java プロセスがいっぱい！？ ・その3 / Windows サービスとして登録している場合は？ ・その4 / WebLogic Server とスレッドダンプ ・スレッドダンプの読み方 その1 – VM 内部スレッドと main スレッド スレッドダンプの取得方法、解析方法について網羅的に説明した資料はあまりないのでちょっと書いてみました。まとまったら侍のドキュメントに追加するつもりです。 スレッドダンプとは、 Java のプロセス内部で動作している各スレッドがそれぞれ何をしているか確認できるものです。 Java のプログラムがフリーズした場合や、パフォーマンス低下が見られる場合などに取得すると、どのスレッドが停滞しているのか、プログラム中具体的にどこで止まっているのかを解析できます。 スレッドダンプは任意のタイミン
ThreadとHashMapに潜む無限回廊は実に面白い？ (1/3) - ＠IT
ThreadとHashMapに潜む無限回廊は実に面白い？：現場から学ぶWebアプリ開発のトラブルハック（10）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） マルチスレッドのトラブルハックはさっぱり分からない… 対処が難しいトラブルといえば、GC（ガベージ・コレクション）とマルチスレッド処理に起因することが多い。 前々回（「肥え続けるTomcatと胃を痛めるトラブルハッカー 」）と前回（「JavaのGC頻度に惑わされた年末年始の苦いメモリ」）の2回にわたってGC、特にメモリ周りのトラブルを取り上げた。そこで今回は、マルチスレッド処理のトラブルの1つ、「レースコンディション（競合状態）
オワコンであるVectorとListの同期の話 - プログラマーの脳みそ
JJUG Night Seminarへ行ってきました - 虎塚にあったjava.util.Vectorの話。 java.util.Vectorは随分前にオワコン化していて、今、新たにVectorを使ってコードを書く人がいたら優しく諌めてあげるべきシロモノ。 「VectorとArrayListだとArrayListの方が同期化されていなくて速いです！」と習った人も多いのではないかと。 public synchronized E get(int index) { if (index >= elementCount) throw new ArrayIndexOutOfBoundsException(index); return elementData(index); } これはJDK7u7のVectorのコードのうちget()の部分の抜粋なのだけど、synchronizedメソッドになってる。s
スレッドダンプの森で覚えた死のロックへの違和感
スレッドダンプの森で覚えた死のロックへの違和感：現場から学ぶWebアプリ開発のトラブルハック（11）（1/3 ページ） 本連載は、現場でのエンジニアの経験から得られた、APサーバをベースとしたWebアプリ開発における注意点やノウハウについて解説するハック集である。現在起きているトラブルの解決や、今後の開発の参考として大いに活用していただきたい。（編集部） スレッドダンプはトラブルハックに非常に有効 Javaを用いたシステムで発生したトラブルを解析する際、スレッドダンプは非常に有効な手掛かりを指し示してくれる。 例えば、連載第3回の「【実録ドキュメント】そのログ本当に必要ですか？」ではログ出力がボトルネックとなったトラブルを、解析ツールを用いたスレッドダンプ解析により発見している。また、連載第10回の「ThreadとHashMapに潜む無限回廊は実に面白い？」では、レースコンディション（競合
HawtDispatch
HawtDispatch: The libdispatch style API for Java and ScalaHawtDispatch is a small ( less than 100k ) thread pooling and NIO handling framework API modeled after the libdispatch API that Apple created to power the Grand Central Dispatch (GCD) technology in OS X. It allows you to more easily develop multi-threaded applications which can more easily scale to take advantage of all the processing cores
Javaで，各スレッドの状態を可視化するツール （マルチスレッドアプリでデッドロックを検出する） - 主に言語とシステム開発に関して
マルチスレッドなアプリケーションで，各スレッドの状態は （１）普通に動作中：緑 （２）ロックを保持しながら動作中：オレンジ （３）ロック待ちのウェイト状態：赤 などの状態を遷移する。 もし（３）が長く続いたら，デッドロックが発生しているとわかる。 こういった複数スレッドの状態を調査するツールとして，フリーの「samurai」がある。 その使い方。 （１）スレッドの同期に失敗しているプログラム まずは，ロックを使わないプログラムの例。 hogeというフォルダの中に，次のクラスを用意： Callee.java（２つのスレッドから共通して呼ばれるクラス） package hoge; class Callee{ private static long sum; // ここのsynchronizedの有無で実行結果が全く違う public static void echo( String calle
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Distinguishing between Java threads and OS threads?
Python の subprocess の preexec_fn の実装と fork のスレッドセーフティー問題
スレッドダンプの読み方
IBM Developer
