>>807
うちでも、Java 8でCountDownLatch版で new Chime().play(i) を連続で500回呼ぶのを10回ぐらい実行したら一回だけDirect Clipスレッドが一つ残りました。
見てみると、
com.sun.media.sound.DirectAudioDevice$DirectClip.run()
の(コメント込みで)10行目ぐらいの lock.wait() で止まっていました。
この箇所の実装をJava 8とJava 12で比較すると少し修正されています。

Java8 の実装だと
while (thread == curThread) {
で thread == curThread が true と判定した後、
synchronized(lock) { ※
で同期化ブロックに入る前に DirectAudioDevice$DirectClip.thread フィールドが変更されていた場合、
そのまま lock.wait() に突入してしまうタイミングがあるように見えます。
つまり DirectClip.run() が※のモニタを取る前に
DirectAudioDevice$DirectClip.implClose() が DirectClip.thread = null として lock.notifyAll() してしまうと、
DirectClip.run() の lock.wait() は来ない通知 (lockのnotify) を待ち続けることになるのでしょう。

Java12 では DirectClip.run() の synchronized(lock) を取ってすぐに
while (!doIO && thread == curThread) {
で DirectClip.thread フィールドをチェックするようになっているので、
絶妙なタイミングで DirectClip.implClose() に割り込まれても大丈夫なようにライブラリが修正されたのでは無いでしょうか。

リリースノートかbug paradeを丹念にチェックしたら、どこかに載っているかもしれません。