なぜ 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) [error] at java.base/java.lang.Thread.start(Thread.java:813) ... [error] at java.base/java.lang.Thread.run(Thread.java:844) OutOfMemory …スレッド作成の失敗。Linux が動いている私のノート PC では、だいたい 11,500 スレッドを作成した辺りでこのエラーが発生します。 Go で無限に sleep する Goroutine を作成すると、これとは大きく違う結果になります。私のノート PC では 70,000,000 の Goroutine を作れましたが、飽きたのでそこでやめてしまいました。なぜ Goroutine はスレッドよりもたくさん作れるのでしょう? この答えを探るためには OS を理解する必要があります。また、これは学術的な問題ではなく、実際に使われるソフトウェアをデザインするための問題です。私は本番環境で JVM スレッドの限界にぶつかった経験が何度もあります。問題のあるコードがスレッドを解放させ損ねたこともあるし、単にエンジニアが JVM スレッドの限界について認知していなかったこともあります。 [Read More]

circleci コマンド悲喜こもごも

CircleCI に導入された circleci コマンドでローカルでも CircleCI の挙動を確認できるようになった。 …というのは嘘である。 気づいただけで、ふたつ不満がある。たとえば CircleCI の cron は、システムレベルの cron がサポートする */x (x: 整数) のような記法をサポートしていない。つまり、5分おきにジョブを走らせたいときに */5 * * * * と 書けない 。かわりに 5,10,15,20,25,30,35,40,45,50,55 * * * * と書かなければならない。しかし、この問題は circleci コマンドの文法チェックでは検知できない。わたしは、これをリモートに push したあとで「うーん、動かないなぁ」と思いながら色々とぐぐって問題を発見した。つらい。 また、ローカル環境で次のように .circleci/config.yml を書くと Error: error authentication with ECR: AWS Credentials not found と怒られる。 version: 2 jobs: build: docker: - image: 00000000000.dkr.ecr.ap-northeast-1.amazonaws.com/my-image:latest aws_auth: aws_access_key_id: $AWS_ACCESS_KEY_ID aws_secret_access_key: $AWS_SECRET_ACCESS steps: - run: name: Greeting command: echo Hello, world. [Read More]

こんにちは、世界

こんにちは、GitLab

日本語のブログを広告のないスペースで書いていきたいと思いたち、GitLab にたどり着きました。GitHub はすでに英語の記事を書くために使っていたので。言語が混ざるのはよくないと思っている派です。

なお、「広告のある場所で記事を書くと想いがゆがむ」と考えるにいたった経緯についてはリンク先の記事をご参照ください。