JavaにおけるOS上のスレッドの取り扱い
Threadのメモリモデルを色々調べていくうちにJavaのスレッドでOSスレッドとどうやって紐付いてるんだろうと思って調べた。
JavaにおけるTheradスケジューラはOSに依存するみたいな説明がされているが、要はJVMプロセス内でOSスレッドを生成してそれをwrapしている。
知識としては知っていたけど、改めて確認してみたかったメモ
public class Main { public static void main(String args[]) throws Exception { Thread.sleep(1000 * 60 * 60); // プロセス終了しないように止めておく } }
javacしてjava Mainでjavaプロセス起動してからPID確認
root@dc4d74fd6f08:/# jps 5684 Jps 5498 Main ←ここにいる
まずはjstackでjava threadを確認
root@dc4d74fd6f08:/# jstack 5498 | grep nid "Attach Listener" #9 daemon prio=9 os_prio=0 tid=0x00007f29a0001000 nid=0x15ba waiting on condition [0x0000000000000000] "Service Thread" #8 daemon prio=9 os_prio=0 tid=0x00007f29dc0c0000 nid=0x1587 runnable [0x0000000000000000] "C1 CompilerThread2" #7 daemon prio=9 os_prio=0 tid=0x00007f29dc0b0800 nid=0x1586 waiting on condition [0x0000000000000000] "C2 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f29dc0af000 nid=0x1585 waiting on condition [0x0000000000000000] "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f29dc0ac000 nid=0x1584 waiting on condition [0x0000000000000000] "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f29dc0aa000 nid=0x1583 runnable [0x0000000000000000] "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f29dc083800 nid=0x1582 in Object.wait() [0x00007f29c5a50000] "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f29dc07f000 nid=0x1581 in Object.wait() [0x00007f29c5b51000] "main" #1 prio=5 os_prio=0 tid=0x00007f29dc009800 nid=0x157b waiting on condition [0x00007f29e36ea000] "VM Thread" os_prio=0 tid=0x00007f29dc077000 nid=0x1580 runnable "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007f29dc01f000 nid=0x157c runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007f29dc020800 nid=0x157d runnable "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007f29dc022000 nid=0x157e runnable "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007f29dc024000 nid=0x157f runnable "VM Periodic Task Thread" os_prio=0 tid=0x00007f29dc0c2800 nid=0x1588 waiting on condition root@dc4d74fd6f08:/# jstack 5498 | grep nid | wc -l 15
jstack的には15個のスレッドがあった
次にpsコマンドでOSスレッドを確認
root@dc4d74fd6f08:/# ps -feL | grep "java Main" UID PID PPID LWP C NLWP STIME TTY TIME CMD root 5498 1 5498 0 16 11:36 ? 00:00:00 java Main root 5498 1 5499 0 16 11:36 ? 00:00:00 java Main root 5498 1 5500 0 16 11:36 ? 00:00:00 java Main root 5498 1 5501 0 16 11:36 ? 00:00:00 java Main root 5498 1 5502 0 16 11:36 ? 00:00:00 java Main root 5498 1 5503 0 16 11:36 ? 00:00:00 java Main root 5498 1 5504 0 16 11:36 ? 00:00:00 java Main root 5498 1 5505 0 16 11:36 ? 00:00:00 java Main root 5498 1 5506 0 16 11:36 ? 00:00:00 java Main root 5498 1 5507 0 16 11:36 ? 00:00:00 java Main root 5498 1 5508 0 16 11:36 ? 00:00:00 java Main root 5498 1 5509 0 16 11:36 ? 00:00:00 java Main root 5498 1 5510 0 16 11:36 ? 00:00:00 java Main root 5498 1 5511 0 16 11:36 ? 00:00:00 java Main root 5498 1 5512 0 16 11:36 ? 00:00:00 java Main root 5498 1 5562 0 16 11:38 ? 00:00:00 java Main root@dc4d74fd6f08:/# ps -feL | grep "java Main"| wc -l 16
ps的には16個あった
psコマンド的にはjstack比べてスレッドが一個多いのは
>root 5498 1 5498 0 16 11:36 ? 00:00:00 java Main
これが大元のjava親プロセスでメインスレッドを作るときにforkして子プロセスを作ってるっぽい(PIDとLWPが同じなので)
- 1Processは1CPUで実行される
- なので概念的にはProcessの中にいくらThreadを作成して並行化しようが、1CPUしか使わない
- そこでLinuxとしてはLWP(Light Weight Process)としてメモリ共有したプロセス(軽量プロセス)を生成し、Threadとして扱う
- 昔のLinuxはLWPがなかったので、単なるThreadだったのでマルチコアで多重スレッドにはできなかった
- 実際、上記のps -feLの結果確認するとLWPのIDが全部違うのでOSスレッド = 軽量プロセスということになっている
スッキリした
マネジメントの秘伝のタレ
今回は私が今までチームマネジメントやヒューマンマネジメントを通して学んだTIPSを整理してみたいと思います。
マネジメント(≒コミュニケーション)を支える技術について都度メモして、自分への戒めとして利用していたものを箇条書きにまとめました。
ある特定の状況だけでしか適用できないものが多いですが、応用はいろいろ効くと思っています。
マネジメントの立場にこれからチャレンジしていきたい人の一助になればと思ってます。
※自分向けのメモを整理しただけなので、一般的にこうあるべきという内容ではありません。
会議編
-全員の参加を促そう
全員の発言機会が均等になっているか常に意識しよう
一言でも意見を言うことによって、その議題を決めたという意識を持てる
- 自分自身(チーム自身)で決めたという感覚に落としもう
「決められたこと」ではなく、「自分たちで決めたこと」という意識を促そう
その決定が実行されなかった時に他責にしずらくなる
- 話が長い人は最後に要約を返してあげよう
「つまり〜〜ということであってますか？」
まわりが飽きてしまうと会議からの離脱が増える
要約してあげることで離脱者を引き戻すことができる
- 視界から消えよう
マネージャーに向かって話すと、複数人なのに一対一のようになってしまう
マネージャーは目を合わせない、ホワイトボードに向かう、後ろに立つ、歩き回るなどして存在を消そう
そうすれば、自然と視線がメンバー同士になる
- 話が長い人はインターセプトしよう
ペンを落とす、くしゃみをする、携帯を鳴らす、トイレに行くなどして会話を途切れた瞬間に話題を変えよう
ただ、あからさまだと失礼なので注意
- わちゃわちゃし始めたときは議論の立ち位置を確認しよう
議論が広がりすぎたときはホワイトボードに簡易マインドマップなどの関連図を書いて、全員で位置関係の認識を合わせよう
空気がけっこう引き締まる
- 空気を占拠しよう
最終的にはマネージャーが責任を持つべきなので、その意思表示のためにも率先して場の空気を占拠しよう
最初にホワイトボード前に立つ、ホワイトボードマーカーを最初に手に取るなどをすればそんな空気になる
- 個人攻撃はすぐにやめさせよう
何も生まれないし、チーム内に禍根の残すきっかけになってしまう
- メンバー同士が衝突し始めたら目線を逃がすように誘導しよう
メンバー同士で正面から目が合った状態で、議論が白熱すると言葉が荒くなったり、喧嘩腰になったりする人もいる
そんな時は、ホワイトボードやノートに書き出したり、モニターを映してみたりして全員の目線を外に逃がそう
- 誰か喋るまで待とう
喋りすぎなマネージャーは議論の邪魔
静かな空気が苦手でも誰かが喋るまで待とう
それでも喋らなかったらそもそも会議自体の内容を見直そう
- よーく観察しよう
寝てる人はいないか、飽きていないか、明らかに他の作業をしていないか常に観察しよう
- 眠たそう、寝ている人がいたらあからさまに意見を求めよう
「寝ないでください」と直接言うのはスマートじゃない
あからさまに何度も意見を求めることによって本人が気づいてくれるのを促そう
それでもだめなら休憩をいれよう
- PCを開けないように机をなくそう
「PCを開くな」や「PCを持ち込むな」と注意するのはクールじゃない
仕組みで解決しよう
- 時間をコントロールしよう
(25分 + 5分) or (50分 + 10分)のワンセット一本勝負
- 議論の決定は必ず実行しよう
実行されないと、発言しても意味がないと思われるので参加意欲が失われる
面談編
- 注意・説教はやめよう
注意する時は、必ず信頼関係が築けてから
そうでない限りは注意・説教しても何も影響しない
- 期待は伝えずに聞いてみよう
「あなたに期待されていることってなんだと思いますか？」
先に質問することでメンバーの意識とマネージャーの意識のギャップを確認しよう
- 相手のテンションを下げないようにしよう
相手のテンションを下げても何も生まれない
テンションをあげるような言葉遣いを意識しよう
- 条件反射を徹底的になくそう
カチンとすることを言われても、反射的に反論しないようにしよう
3呼吸ぐらいは置こう(短気だと思う人は5呼吸ぐらい)
もしくは、スルーしてから面談の最後にどうしても言いたかったら言おう
- 権利と義務はセットではないことを意識しよう
権利は権利、義務は義務
納税していない人でも選挙権はある
- 期待をはっきりと伝えよう
どういう人材になってほしいか誠実にはっきりと伝えよう
実際に相手のやりたいこととマッチするかは別にして、まずは伝えよう
- 徹底的に相手の立場を想像しよう
どのように伝えられたらテンションがあがるか？
どのような言葉を使われたら気分が悪いか？
- うわべの会話はやめよう
うわべで話していると相手は必ず気づく
本心から興味を持っていないことは必ず伝わる
うわべで褒めても必ず見抜かれる
そのためには日頃から観察しよう
- 指示ではなく、提案をしよう
条件、目標、作業など相手が決めきれない時は複数提案してあげよう
ちょっとの違いでもいいから複数だそう
"選択した" という行為によって、自分で決めたことになる
- 相手の心を揺さぶろう
扇動的な言葉を使って、相手の心を揺さぶろう
そこにモチベーションを上げるヒントがある
- 評価しないように意識しよう
マネージャーがその人の全てを評価できると思うことはおこがましい
評価はさまざまなプロセスで最終的に決まる
面談しただけの印象で固定観念に落とさないようにしよう
- 直接プレッシャーをかけないようしよう
直接的なプレッシャーは人を潰すだけ
期待をする、期待をされることでプレッシャーは相手の中で勝手に醸成される
マネジメントは技術です。
本もたくさん出ていますし、バイブルと言われているような有名な本もあります。
知識をつけて、実践して、失敗して、工夫して、身につけていくものです。
プログラミングと全く同じですね！
wordpressのdockerコンテナからRDSに接続する
今度はRDSに接続してみる。
RDSはとりあえずdevでぽちぽち立ち上げ。
mysql -h ${RDS ENDPOINT} -P 3306 -u ${RDS USER} -pで接続できることを確認。
接続できない時は立ち上げたVPC上のSecurity Groupの設定で接続元(この時はローカルのMacから接続してたので自宅のグローバルIP）とポートを許可する
RDSに接続できることを確認できたらwordpressのコンテナ起動オプションに
https://hub.docker.com/_/wordpress/
に従い -e オプションで接続先のDB設定を追加する
docker run --name wordpress -e WORDPRESS_DB_HOST=${RDS ENDPOINT} -e WORDPRESS_DB_USER=${RDS USER} -e WORDPRESS_DB_PASSWORD=${RDS PASSWORD} -p 80:80 -d wordpress起動できたら前回同様にブラウザでアクセスしてみる
#dockerホストのIP確認
$ docker-machine ip wordpress >192.168.99.100
http://192.168.99.100にアクセス -> OK
同一dockerホスト上でwordpressとmysqlをそれぞれのdockerコンテナで起動して接続してみるメモ
※環境はMacOS
※virtualBoxとdocker-machineはセットアップ済み
#docker-machineでwordpress起動用のdockerHostを起動
$ docker-machine create --driver virtualbox wordpress
# 環境変数を設定
$ eval "$(docker-machine env wordpress)"
#mysqlのdockerコンテナを起動
$ docker pull mysql $ docker run --name mysql -e MYSQL_ROOT_PASSWORD=mysql -d -p 3306:3306 mysql
#接続の確認
mysql -h $(docker-machine ip wordpress) -uroot -p
dockerでwordpressを起動
$ docker pull wordpress $ docker run --name wordpress --link mysql -p 80:80 -d wordpress
ブラウザでアクセスしてみる
#dockerホストのIP確認
$ docker-machine ip wordpress >192.168.99.100
http://192.168.99.100にアクセス -> OK
Raspberry Pi2 Model Bでmdadmを使ったraid1構築
apt-get install mdadmでmdadmをインストール- sdaとsdbをfdiskで初期化してから、それぞれsda1とsdb1のパーテーションを作成
mdadm --create /dev/md0 --level=raid1 --raid-devices=2 missing /dev/sda1でまずはsda1だけの片肺状態で/dev/md0を作成mkfs -t ext4 -c /dev/md0で/dev/md0にext4のファイスシステムを作成する- /etc/fstabに
/dev/md0 /data ext4 defaults 0 0を追記する - 試しに
mount /dev/md0でマウントしてみる→OK mdadm --add /dev/md0 /dev/sdb1で残りのsdb1をraidに参加させる
Macで画像のexifを編集する
exiftoolをインストールする
www.sno.phy.queensu.ca
対象のディレクトリで以下を実行
cd target_dir exiftool -alldates='2016:2:04 00:00:00' -overwrite_original *
haskellでなぜfoldrだと無限リストが扱えてfoldlだと扱えないのか
畳込関数fold：foldrとfoldlの違い (あるいはfold_right, fold_left） - 一歩前進
無限リストをfoldrで扱う(foldlでは扱えない)
haskellは遅延評価が特徴。
式の評価は外側から行う。
つまり外側の評価をするその時に内側の結果が必要なら計算する。
算数で例えると
(1 + (2 * 3))
という計算の場合は、外側の1 + の部分を計算するためには(2 * 3)の結果が必要なので、しゃーなしにその時に(2 * 3)を計算するみたいな感覚っぽい。
なので
foldl (+) v [x0,x1,...,xn] = (...((v + x0) + x1) ...) + xn foldr (+) v [x0,x1,...,xn] = x0 + (x1 + (... (xn + v)...))
のような場合だと
foldlの場合は一番外側の式がxnの計算、つまり無限の終端を対象とする計算になってしまうので計算不可能。
foldrの場合は、一番外側がx0でリストの最初の数を対象にしているので計算(を開始することは)可能。
ということみたい。
試しにGHCIで
Prelude> foldl (+) 0 [1..]
は返ってこない
Prelude> foldr (+) 0 [1..] [2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58,60,62,64,66,68,70,72,74,76,78,80,82,84,86,88,90,92,94,96,98,100,102,104,106,108,110,112,114,116,118,120,122,124,126,128,130,132,134,136,138,140,142,144,146,148,150,152,154,156,158,160,162,164,166,168,170,172,174,176,178,180,182,184,186,188,190,192,194,196,198,200,202,204,206,208,210,212,214,216,218,220,222,224,226,228,230,232,234,236,238,240,242,244,246,248,250,252,254,256,258,260,262,264,266,268,270,272,274,276,278,280,282,284,286,288,290,292,294,296,298,300,302,304,306,308,310,312,314,316,318,320,322,324,326,328,330,332,334,336,338,340,342,344,346,348,350,352,354,356,358,360,362,364,366,368,370,372,374,376,378,380,382,384,386,388,390,392,394,396,398,400,402,404,406,408,410,412,414,416,418,420,422,424,426,428,430,432,434,436,438,440,442,444,446,448,450,452,454,456,458,460,462,464,466,468,470,472,474,476,478,480,482,484,486,488,490,492,494,496,498,500,502,504,506,508,510,512,514,516,518,520,522,524,526,528,530,532,534,536,538,540,542,544,546,548,550,552,554,556,558,560,562,564,566,...
で一応実行できる。
