エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

SpringBootのアプリで、JMHを使ってみた

Java

メソッドのちょっとした書き方の違いによる速度の計測をしたくて（Micro Benchmarkというらしい。対義語はMacro Benchmark）、JMHで計測をしてみました。

JMHのオフィシャルページを見ると、mvn archetype:generate なるものが出てきて「なんじゃこりゃ？」だったり
適当にググったページでは、そもそも古くて今は動かないサンプルだったりと、どうにもわかりにくかったのですが、こちらのページのとおりに試してみたところ、うまくいきました。
Microbenchmarking with Java | Baeldung

それでもハマったところ
1. SpringBootのmain methodがあるクラスに、Benchmark用のmain methodも書いたところ、以下のようなエラーが出て何故か起動できず。

# JMH version: 1.21
# VM version: JDK 1.8.0_121, Java HotSpot(TM) 64-Bit Server VM, 25.121-b13
# VM invoker: C:\Program Files\Java\jdk1.8.0_121\jre\bin\java.exe
# VM options: -Xmx3000m -Ddebug -XX:TieredStopAtLevel=1 -Xverify:none -Dspring.output.ansi.enabled=always -Dzookeeper.address=b -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=51723 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost -Dspring.liveBeansView.mbeanDomain -Dspring.application.admin.enabled=true -javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2018.1\lib\idea_rt.jar=51724:C:\Program Files\JetBrains\IntelliJ IDEA 2018.1\bin -Dfile.encoding=UTF-8
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: rakuten.travel.availability.calculation.api.BenchmarkRunner.benchMarkKick3

# Run progress: 0.00% complete, ETA 00:10:00
# Warmup Fork: 1 of 1
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 51723; nested exception is: 
	java.net.BindException: Address already in use: JVM_Bind
<forked VM failed with exit code 1>
<stdout last='20 lines'>
</stdout>
<stderr last='20 lines'>
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 51723; nested exception is: 
	java.net.BindException: Address already in use: JVM_Bind
</stderr>

→　上記ページのように、mainメソッドを書くための専用のクラスを別に作ったところ、問題なく動作。

2. テスト対象のメソッドにパラメータを渡す方法がわからなかった
→　これも上記ページに書いてある


おまけ
とあるメソッドのリファクタ結果

Benchmark                        Mode  Cnt       Score        Error  Units
BenchmarkRunner.benchMarkKick1  thrpt    5   29271.881 ±   1088.831  ops/s
BenchmarkRunner.benchMarkKick2  thrpt    5   74336.732 ±   4597.243  ops/s
BenchmarkRunner.benchMarkKick3  thrpt    5  280990.396 ± 185017.629  ops/s

1はもとのまま。2はちょっとリファクタリング。3はもっとリファクタリング。
もとより桁一つ速くなった。うひょー！

Mavenで実行しているTestに割り当てるヒープを増やす方法

Java

Maven Surefire Pluginを使う。
https://maven.apache.org/surefire/maven-surefire-plugin/

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
    </configuration>
  </plugin>

ぐぐると、MAVEN_OPTSに書けばいい　とか、　Jenkinsの場合はGlobal MAVEN_OPTSに書けばいい　とか出てくるんだけど、
これは、MavenのJavaプロセスに割り当てるメモリ。
その中で実行されるテスト用のメモリは別に確保される。

実際、テストコード内で以下のように割り当てメモリを書き出してみると

int mb = 1024 * 1024;
Runtime runtime = Runtime.getRuntime();
System.out.println("Max Memory:" + runtime.maxMemory() / mb);

MAVEN_OPTSに何を書いても増えないし減らない。

Chrome Tech Talk Night

events.withgoogle.com
Google さんで行われた、Chrome Tech Talk Night　に参加してきました。

弊社の新人研修依頼、10年以上ぶりに森タワーのオフィスに入ったなぁ　とか　しょうもないことを思いながら。


そもそも私、フロントエンジニアではないので、正直細かいところはよくわからんというか的はずれな理解だった感も否めないのですが…


発表する人、発表する人、

  • これは標準化される（予定である／されている）
  • まだ絶賛仕様決めてるような段階だけどGithubに最新のリポジトリがある
  • オンラインでオープンにディスカッションされている


くっ　ここはそういう世界か…！
と。


テクノロジー会社としてのあるべき姿をまざまざと見せつけられた気がしました。

なので忘れないようにブログ。

"Fiber" で 100万スレッドが実行可能に！？ - Project Valhalla とProject Loom : JavaDayTokyo 2018 参加レポート2 #JavaDayTokyo

Java JavaDayTokyo2018

Project XXX系の話について、Project ValhallaとProject Loomについて聞きました。
どちらも講演はDavid Buckさん*1。

残念ながら、どちらもJava11には入らないので、LTSのリリースサイクルを考えるとまともにサービスで使えるのは早くて2021年…
とはいえ、どちらもとても夢のある話でした。

Project Valhalla

Value Types (値型）

class Point {
   int x;
   int y;
}

のような、プリミティブ型をフィールドとして持つクラスがある時に

  Point[] points;

配列を作ると、各Pointインスタンス毎にヘッダを持ってしまい、大きなメモリのオーバーヘッドが発生します。
メモリの最適化だけ考えると

  int[] xList;
  int[] yList;

とプリミティブ変数の配列を宣言するのが最も良いのですが、これではせっかくのオブジェクト指向が台無し。

そこで、「例えば*2」

value class Point {
   int x;
   int y;
}

このようにクラス宣言した際に、さも intの配列が2つあるかのようなメモリ確保がされる…　というのが概要です。
これによって、省メモリ化に加えて、参照の高速化も図ることができるようになります。

ここまでは昨年のJavaDayTokyoでも既に紹介されていました。

Generic Specialization (ジェネリックの特殊化）

上記を実現する過程で、このようなことができる様になる…　と紹介されました。

ArrayList<int> xList;

要はプリミティブ型がほとんど普通のオブジェクトのように使えると。
さらに、intStreamのような（普通のstreamと別にメソッドを用意しなくてはならないような）「ダサい」対応も不要になるとのことです。

とは言えいろいろ悩んでるらしい

とは言え、この「ジェネリックの特殊化」をいざ実装しようとすると悩ましい課題が多いらしく…　まだまだ実用化には時間がかかりそうでした。

実際の所、どのくらい使えるんだろう

現実的な利用シーンを考えると、フィールドにプリミティブしか持たないクラスというのはあんまりない気も。
せめて、StringやLocalDate系が混ざっていてもうまいこと扱っていただけるようになると良さそうなのですが。

Project Loom

こちらがタイトルの、”100万スレッド”です。
現在のJVMでは、JVM上のスレッドは、OSが管理するスレッドとマッピングされています。それぞれのスレッドは、用途が異なるかもしれません。あるスレッドは複雑な暗号化に使われるかもしれないし、またあるスレッドは単に変数を一つ書き換えるだけの簡単な処理に使われるかもしれません。

しかしながらOSは、アプリケーションのコードを知らないため、各スレッドの用途もわかりません。そのため、どのスレッドも一律、「何にでも使えるスレッド」を用意することになります。

ここで、「Fiber」という考え方が登場します。Fiberは、OSではなく、Javaのruntimeやユーザコードによって支配されるスレッド。アプリケーションはスレッドの用途を知っているため、無駄のないスレッドを効率的に作ることが可能です。その結果、OS管理のスレッドに比べてなんと1000倍ほど数のスレッドが作れるようになるとのこと。
それだけOSが作るスレッドには「無駄」があるそうです。

ブロッキングと非同期

ちょうど一年前のJavaDayTokyoで聞いた話ですが、
taichiw.hatenablog.com
ブロッキングな処理はスケールしにくい、という問題点があります。
その対策として、非同期（ノンブロッキング）に処理を制御する、という方法があるものの、プログラミングやデバッギングが難しい、という問題があります。

この双方の問題を解決するのがFiber.
スレッドモデル（＝ブロッキングな処理）であるため取扱が簡単であるにもかかわらず、スケーラビリティに優れるという夢のようなお話です。

言ってることが未来

Fiberはスレッドなので、「どんな処理が」「どこまで進んだか」が管理されています。
他方、JVM上で管理されているオブジェクトなので、Serializeが可能とのこと。
その結果何ができるようになるかと言うと…

  • 実行中のスレッドをSerializeして保存。JVM停止。→JVMを起動してスレッドの続きを実行
  • 分散データベースに於いて、「処理を他のサーバに転送」

と言ったことができるようになるとのこと。

…　よくわかりません。

まだ検討段階

実際の所、まだまだ開発が始まったばかりでCommitもないとか。
早くて今年中にアーリーアクセスが出る……　かも。

とのことでした。

しかしとっても夢のある話。実現が楽しみです。

*1:基調講演でFlight Recorderのデモもされて…　来週末の JJUG CCCでもセッションがあるそうで…　寝不足で頭が回ってないといってましたがこれだけ準備してたら、そらそうでしょうなぁ…

*2:まだ決まったわけではない…　と強調されてました

Java11について : JavaDayTokyo 2018 参加レポート1 #JavaDayTokyo

Java JavaDayTokyo2018

今年もJavaDayTokyoに参加させていただきました。

今年の自分なりのテーマは、以下についての情報収集でした。

  • 半年後にリリースされるLTSバージョンであるJava11の新機能
  • その他今後追加される機能について
    • 特に、一昨年くらいから聞いているProject Valhalla。結構な数のコレクションをゴリゴリ処理するのが最近の自分のお仕事の大事なところなので、どうなったか興味アリ

このエントリでは主にJava 11についてまとめます。

Java 10とJava 11 の差

Java 10 からJava 11への追加機能として、現在8件のJPEが予定されているそうです。
http://openjdk.java.net/projects/jdk/11/

この内、コードの書き方に影響がありそうな、文法面での変更は、Project Amberの一つでもあるこれだけかなぁ…と。
JEP 323: Local-Variable Syntax for Lambda Parameters

ということで、Java8 → Java11の差は雑に言うと、
Project Jigsaw + "var"
と言っていいかなぁ…　という気がしました。

櫻庭 祐一 さんのセッション、「Java SE 10、そしてJava SE 11への移行ガイド」でも、8つのチェックポイントが紹介されていましたが、ハマりどころになるのは概ねJigsaw絡みと感じました。

Ask the Experts! でもそのような回答だったようです。

11 の次の LTS バージョンは 17 !

Java 11の次のLTSバージョンは、2021年9月にリリースされるJava17とのこと。
私、1年半に一回LTSが出るものだと思っていたんですが、3年後なんですね。オリンピック終わっちゃってるのかぁ…

Mission Control と Flight RecorderがJDK11からオープンソースに

これまで有償ツールだったMission ControlとFlight Recorderが、JDK11から無償で使えるようになるとのこと。
基調講演内でデモがあったのですが、パフォーマンスの問題を見つけるのにずいぶん使えそうに見えました。
気になる…！

一つのドキュメントに、いろいろ一緒に書くのは難しかった話

・ビジネス上の要件
・自分のところのAPIはどう振る舞うべきか
・どうしてそう決めたか（ちょっともとの要件からねじれてる）
・中はどう作るべきか

を、全部一箇所に書くのは結局無理でした。

なので
・ビジネス上の要件
・自分のところのAPIはどう振る舞うべきか（の、一段階抽象化したやつ）
だけを書いて

・どうしてそう決めたか　→　こうすれば「想定されてるケース全部うまくいくから亅で逃げる
・本当のAPIの振る舞い　→　別に書いたテストで表現
・どう作るか　→　上のテストが通れば何でもいいよ

という体裁に。
俺が伝えるべきことは伝えられるドキュメントになったと思うけど、
俺は一体何屋なんだ（笑）

チームビルディングのために性格診断を使ってみたい

Team

チームビルディングのために性格診断を使ってみたい　…と思っています。

背景

今、一緒に開発をしているチームのコミュニケーションを、より円滑にしたいと考えています。
各メンバーが、もっと他のチームメンバーの、「良いところ」や「自分との違い（どっちが良い悪いではない）」を発見することによって、より良いコミュニケーションと、そこから生まれるチームワークが実現できると考えています。

ジョハリの窓

私が、チーム内のコミュニケーションがより円滑になると考えている根拠が、ジョハリの窓です。
ジョハリの窓 - Wikipedia
f:id:taichiw:20180429170038p:plain

IとIIの間の敷居、IとIIIの間の敷居を移動させて「公開された自己」の領域が広がることでコミュニケーションが円滑になる、という理論。
このうち、IとIIIの間の敷居を移動させ、Iの領域を広げるために、性格診断が使えそうというアイディアです。
f:id:taichiw:20180429170458p:plain

きっかけ

一番始めにこの手のことを考えたのは一昨年のXPまつり。
「ピンポンゲームを使ったチームビルディング」の話を新井さんから聞いたときでした。
残念ながら記録を残していなかったので記憶ベースの話になりますが…

  • ゲーム内で、自身の自己開示を進める。例えば
    • 「自分はプレッシャーに弱い」
    • チームの勝利は大事だが、自身の記録も大事にしたい
  • ゲーム内でチームメンバーの性格を把握したことが、業務内でのコミュニケーションに生きる

といった内容だったと思います。
これすごく良い！試そう！と思った記憶があります。（思っただけで試さなかったのですが…）

そして1年半ほど経過した先日、「ふりかえりワークショップ*1」に参加した際、今度は、
性格診断を使って自己開示する
というアイディアを聴きました。（このときに、前述のピンポンゲームの話も久しぶりに思い出しました…）

今の私のチームは、メンバーが半々ほどで東京と上海に分かれており、アジャイルのゲームのように同じ場にいることを前提としたアクティビティを使うことが難しいです。
そこで、この性格診断を使った方法、ありなんじゃないかな？　と思った次第です。

こんな進め方を考えています

性格診断は、
MBTI理論をもとにしている、
無料性格診断テスト | 16Personalities
の利用を考えています。

  • ふりかえりワークショップで教えてもらったのがMBTIだったこと
  • 上記サイトは非常に多くの言語をサポートしていること（現在のチームは多国籍で、母国語が異なるメンバーで構成されています）

が理由です。

事前準備

・性格診断を受ける
・結果の中であたってる！と思ったところを抜粋
・具体的なエピソードを思い出し、上記抜粋と併記

ここまでを、事前準備として参加者に行っておいてもらいます。

なお、前述のとおり私の今のチームは母国語が異なるメンバーで構成されているため、
性格診断と結果の確認は母国語版で、
共有のための書き出しは英語版で行ってもらうことを想定しています。

自己の開示

上記、準備したものを参加者それぞれに共有してもらいます。
この共有の仕方が実は悩みどころでして…

真っ先に思いついたのは、全員同じ場で（拠点はビデオ会議でつないで）、順番に発表してもらう、「同期」方法です。
ただ、この方法ですと、他の人は基本的に受け身になってしまう、という問題があります。
全部で9人いるので、一人3分としても27分、5分なら45分。順番に聞いていくのってなかなか疲れますよね。
他の参加者が発表者に対してフィードバックを行うことも考えたのですが、できるとしたら

  • たしかにあなたはそういうところがありますね、という同調。
  • 発展させて、他にもこういう事例もありますよね、という「事例の追加」

あたりでしょうか。

続いて、非同期な方法も考えてみました。
せっかく事前準備をしてもらうので、事前準備を集めて共有し、あとは各メンバーに読んでもらうという方法です。
こちらは、「ちゃんと読んでくれるかなぁ…」　という懸念が募ります。

言葉ではない方法で共有する方法も考えました。
こちらのブログでは、結果を四象限上にマッピングしているようで、
qiita.com
このような形で、パッと見でメンバー9人全員の結果がわかるような形にできれば、そこから興味を持って話を聞くなり読むなりしてくれそうです。

とりあえず一回やってみたい

ということで、いきなりチームでやると難しそうなので、まずはリハーサルをやってみたいなと思っています。
付き合ってくれそうな方に声をかけて、やらせてもらおうかなぁと思っています。
（もしくはご興味がある方、是非一緒にやりましょう）

ちなみに私の結果

“仲介者”型の性格 (INFP-A / INFP-T) | 16Personalities
でした。

あたっているな、と思ったのは以下の点です。

  • 「同じ考えを持つ人々を見つけて共に過ごす時、そこで感じる調和が、仲介者型にとって、喜び」

→ 逆に、ある集団内で意見が対立していると、大変居心地が悪い。健全な組織のために時には意見対立も必要だ…と思いつつ、中間状態を見ているのがめちゃ辛い。*2

  • 「難なく比喩表現やたとえ話を用い、シンボルを理解し生み出しながら、自分の考えを共有できます」

→ 比較的複雑な概念、難しい概念を、わかった気にさせる『デフォルメ』は得意な方だと思う

  • 「一度に多くのことをやろうとすると力尽き」

→ やることが複数になるとすぐパニックになります

  • 「生きて行く上で欠かせない日常生活の維持を疎かにしてしまう可能性もあるので注意しましょう」

→ 特に『ノッてる』ときは、食事すらしたくないときがある。*3

  • 「放っておくと、まるで隠者のように引きこもったまま連絡が途絶え」

→ 『俺のこと放っておいてほしい』とき、よくあります。ひとりで考え事に集中したいです。*4

超余談

この投稿が、ちょうど本ブログの100記事目だったようです。
2011年11月、サンフランシスコへの長期研修中に始めて、ここまで約6年半かかりました。
タイトルのとおり毎週書いていたら、わずか2年弱で達成されていたはずなのですが、3倍半程かかりました（笑）

*1:別途ブログを書く予定です！　…というか書いてる途中で、こちらの記事が独立してしまいました

*2:チームの仲が悪い　と感じているのもここから来ているのかも。違う性格の人であれば、「普通だな」くらいに思うのかもしれません

*3:なので、会社で誰かとランチの約束をするのが苦手だったりします。でも寂しがり屋です。メンドウですね

*4:でも、かまってほしい寂しがり屋です。メンドウで（略）