スレッドダンプを解析する地獄とFastThreadというWebサービス - 理系学生日記
スレッドダンプというと、JVM 言語に関する運用でマジで困ったときの頼みの綱みたいなイメージある。マジで困ったとき、じゃなくて、カジュアルに見れば良いんだけど、スレッドダンプのフォーマットが異常すぎてつらくなる。 そもそもなんなんだこのゴミみたいなフォーマットは。 一体誰がどういう思想の元でこのフォーマットを決めたのかさっぱり分からないし、人類を苦しめるために未来から来た AI が勝手に策定したのではないか。 "[ThreadPool Manager] - Idle Thread" #42 daemon prio=5 os_prio=31 tid=0x000000012a3a7800 nid=0x15503 in Object.wait() [0x000070000ab66000] java.lang.Thread.State: WAITING (on object monitor) at
FlexSC-Threadsの紹介 -プログラムの変更無しにマルチスレッドプロセスを高速化
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
イベントはスレッドに比べて何故ダメなのか (Why Events Are A Bad Idea) | yunabe.jp
並行処理をプログラミングする方法は大別すると、 スレッドなどを利用した同期処理的な書き方と イベントを利用した非同期処理的な書き方があります (イベントループ)。 最近 C10K問題 が有名になったことや、 Node.js が流行っていて Node.js のメリットとしてイベントモデルであるため C10Kが解決されるというのが上げられていたりして、 イベントモデルのスレッドに対する優位性が注目されることが多いように思います。 しかし個人的な経験として、ある程度以上複雑なプログラムを書く場合、 イベントモデルで非同期処理を多用してプログラムを書くとスレッドで同期処理を使ってプログラムを書いた場合に比べてプログラムの可読性・保守性が著しく悪くなり、 バグが発生しやすくなるように感じます。 しかも並行処理で起こるバグは特定の処理が特定の順序で実行された場合のみ起こるようなことが多く、 再現性が低
Performance without the event loop | Dave Cheney
This article is also available in Japanese, イベントループなしでのハイパフォーマンス – C10K問題へのGoの回答 This article is based on a presentation I gave earlier this year at OSCON. It has been edited for brevity and to address some of the points of feedback I received after the talk. A common refrain when talking about Go is it’s a language that works well on the server; static binaries, powerful concurrency, and high per
Raw Linux Threads via System Calls
This article has a followup. Linux has an elegant and beautiful design when it comes to threads: threads are nothing more than processes that share a virtual address space and file descriptor table. Threads spawned by a process are additional child processes of the main “thread’s” parent process. They’re manipulated through the same process management system calls, eliminating the need for a separ
Concurrency Utilitiesの「再」まとめ - Java8対応版 - argius note
以前、このような記事を書きました。 Concurrency Utilitiesを使った並列処理・マルチスレッドのおさらい (2013-12-26) 前回の内容は、Concurrency UtilitiesだけでなくJavaのマルチスレッドの話も一部含んでいましたが、今回は、Concurrency Utilitiesだけにフォーカスして、全体が分かるように整理してまとめ直しました。 目次 概要 準備 タスク・フレームワーク (Executor) 同期キュー シンクロナイザー 並行処理コレクション 時間単位 アトミック値型とアトミック操作 ロック・フレームワーク 概要 今回は、Concurrency UtilitiesのAPIをいくつかのグループに分類し、それぞれのグループの主要な機能を「広く浅く」紹介する、という形式でまとめています。 パッケージ単位で分け、それからjava.util.con
Concurrency Utilitiesを使った並列処理・マルチスレッドのおさらい - argius note
この記事は、個人的なおさらいのための、Java Concurrency Utilitiesの一部を使ったサンプルとメモです。 目新しいものは特にありません。 記事内のサンプルとAPIドキュメント参照はJava7(Java SE 7)を基準にしていますが、Java Concurrency Utilities自体は一部を除いてJava5(Java SE 5.0)から使えるようになっています。 あと、いつものことですが、画像がありません。 追記(2014-01-05): この機能の呼称は (Java) Concurrency Utilities が公式で、この記事内の"Utility"というのは正確ではない＋混在していますのでご注意ください。ごめんなさい。 追記(2014-08-15): この記事は、キーワード"Java Concurrency Utilities"でGoogle検索した時に2番
Javaのシステムスレッドについて調べてみた (Java8) - argius note
システムスレッドについて、あまり知らなかったので、調べてみました。 それ以外にも、APIで生成されるスレッドや、スレッドグループについても、少し触れています。 ※GrepCodeは2018年5月頃からサービスが利用できなくなっています。記事中のリンクはGrepCodeのものがそこそこ多いので、ご注意ください。 参考リンク HotSpot Runtime Overview - OpenJDK JVM Internals (JamesDBloom - Blog) Java SE 8 API仕様 GC: openjdk-8-b132.jar - GrepCode Java Project Source Mirror of OpenJDK repositories - GitHub 目次 はじめに 実行環境 システムスレッドの名称と簡単な説明 APIを使用したときのスレッド おわりに はじめに シ
CGI、マルチスレッド、シングルスレッド+イベント駆動そしてNode.js - wyukawa's diary
僕はNode.jsとはそんなに関わりはなくてshibを使っているのが唯一の接点なんだけど、http://mozaic.fm/post/99334017903/10-node-jsを聞いてたら大変に面白かったので面白かった部分について書く。 このpodcastは全部で2時間以上あって全部聞くのはなかなか辛いんだけどw 僕が面白いと思った部分はCGI -> マルチスレッド -> シングルスレッド+イベント駆動 という技術の歴史的な経緯のあたりです。 インターネットが出た当初は同時アクセス数も少ないのでCGIが一般的でリクエストがくるたびにプロセスが起動してさばくというモデルで全然問題がなかった。 それがECサイトとか出てきて同時アクセス数が増えてくるとCGIモデルが辛くなってきたので、リクエストをスレッドでさばくマルチスレッドモデルが登場した。 余談だが僕が2002年に社会人になってServl
あなたとスレッドダンプ - 第八回 #渋谷java
第八回 #渋谷java で発表した「あなたとスレッドダンプ」です。 スレッドダンプの使いみち、取り方、読み方について説明しています。 スレッドダンプこわくない。
スタックトレース/スレッドダンプの読み方 その1 – VM 内部スレッドと main スレッド – yusuke.blog
スレッドダンプの取り方は前に説明した通りです。 #二年近く前ですが・・・ しかし、スレッドダンプは取得しただけでは役に立ちません。 もちろん、スレッドダンプは解析して初めてトラブルシューティングやチューニングに役立つものです。 そこで、今回からは具体的にスレッドダンプの中身を見ていきましょう。 説明に使うアプリケーションはこんな感じ。起動したら "Hello World! と表示して10秒間スリープするという簡単なもの。 public class ThreadTest1{ public static void main(String args[]) throws Exception { System.out.println("Hello World!"); method1(); } private static void method1() throws Exception { Threa
Five things that make Go fast | Dave Cheney
Anthony Starks has remixed my original Google Present based slides using his fantastic Deck presentation tool. You can check out his remix over on his blog, mindchunk.blogspot.com.au/2014/06/remixing-with-deck. I was recently invited to give a talk at Gocon, a fantastic Go conference held semi-annually in Tokyo, Japan. Gocon 2014 was an entirely community-run one day event combining training and a
並行処理プログラミングの深淵~Java仮想マシン仕様 スレッドとロック~
The document discusses various aspects of concurrency in Java such as synchronized blocks, volatile variables, and reordering issues. It provides examples of how to properly synchronize access to shared mutable data using locks and compares the behavior of synchronized and volatile. The final sections cover atomicity in Java and how the volatile keyword prevents instruction reordering problems but
Webサーバのマルチスレッドでの実装における優位性をLinux Kernel 3.3のソースから読み解く
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 表題の通り、現行のカーネルの実装において、マルチスレッドとマルチプロセスでの実装の優位性はどういう所にあるのかを知りたい、というのが今回の調査の意図だ。 そのために、前提知識としてマルチスレッドとマルチプロセスの特徴について、カーネルのソースを見ていきたいと思う。カーネルの海に飛び込むには、やはり最新のLinux Kernel 3.3のソースを選択することにした。前置きの段階で少し長くなってしまいそうだ。ではカーネルの海に飛び込みたいと思う。 とはいっても、まずは最初の一歩が必要なので、当たりをつけようと思う。キーワードは、 マルチスレッド マルチプロセス コンテキストスイッチ メモリ空間の共有 TLB（トランスレーション・ルックアサイド・バ
第19章 スレッド
rubyスレッド スレッドは「みんな一斉に動く」というのが建前だが、実際には少しの時間ず つ順番に動いているわけだ。厳密に言えばマルチCPUのマシンでそれなりに工 夫すれば同時に二つ動いたりもできるが、それでもCPUの数以上のスレッドが あればやはり順番に動かなければならない。 つまりスレッドを作り出すためにはどこかで誰かがスレッドを切り替えてやら ないといけないわけだが、その手法には大きく分けて二種類ある。 カーネルレベルスレッドと ユーザレベルスレッドだ。これはどちらも読んで字の如く、ス レッドというものをカーネルで作るかユーザレベルで作るかという違いである。 カーネルレベルならマルチCPUを生かして複数のスレッドを同時に動かしたり もできる。 ではrubyのスレッドはどうなのかと言えば、これはユーザレベルスレッドで ある。 そして（それゆえ）同時に動けるスレッドは厳密にただ一つと制限
Thousands of Threads and Blocking I/O
This document summarizes a talk about different server models using synchronous I/O (thread-per-connection) versus asynchronous I/O (NIO). The talk discusses the evolution of server designs from simple multithreaded models to NIO-based approaches. It presents arguments for both approaches but notes that benchmarks showed synchronous I/O to be faster than NIO in some cases, contradicting common bel
Writing Interactive Web Applications with Web Actors
January 28, 2014 Writing Interactive Web Applications with Web Actors By Ron The actor model defined by Carl Hewitt and then evolved and popularized (well, relatively popularized) by the Erlang programming language, has become a very appropriate choice for designing certain kinds of software. Those groups of isolated processes communicating with one another by passing messages back and forth are a
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Querying Your Database from Millions of Fibers (Rather than Thousands of Threads)
Comparision of different concurrency models: Actors, CSP, Disruptor and Threads
Many Blocking VS Single Non-Blocking Workers