Java入門・初心者質問スレ Part.9
■ このスレッドは過去ログ倉庫に格納されています
馬鹿すぎてワロタw お前も回れ右 どうせ自演だろうけど いまだに原因不明ですが、0.5秒ごとに new chime().play(n); (n は 0 - 2) を500回繰り返すというプログラムにしたら、 時々プログラムが1秒くらい止まってその後 Direct Clip が増えるという現象が見られました。 これって何か関係ありますかね? ここはお前の日記帳じゃねーから 入門書からやり直してこいカス >>716 ここは初心者スレだ 言いたいことは分かったから用が済んだら出て行ってくれないか? お前の様にロクに回答もせずただ人をこき下ろすだけの存在ってすげー迷惑なんだよ 初心者スレだからって初心者という言葉が免罪符になるとは限らない だって君、初心者未満なんだもん そういうのに答え教えても何も身に付かないんだよね >>721 何ひとつ答え教えてねーヤツがよく言うわw とっとと失せろ卑怯者! わかったわかったw while(running) これ見て何か気づくか? >>719 色々試してみても変わらないです。 つけられるメソッド全部に synchronized をつけたら全く Direct Clip が消えなくなりました。 君たちさ詰められたときに逃げられるように曖昧なことしか言ってないようだけど そういうのやめようよ フラグの同期が取れてないのが原因なのかね? デッドコードしてコンパイル時に消されてるとするなら 一回もcloseは呼ばれない 質問者が確認したところではcloseは呼ばれてる そのことからデッドコードとして消されてるわけではない 可視性の問題かなあ、仮想マシンでメモリの同期が保証されない場合 CPU依存になるわけだけれどもインテルのCPUだと強いメモリモデルだから 可視性の問題はほとんど起こらなかったりするわけだけれども 君たちは具体的にどういう問題だと認識してるわけですか? 回答を教えてもらう立場の奴が取る態度じゃないから ノーアンサーでフィニッシュ! >>726 > while(running) 君の回答はこれだっけ? これでいんだっけ? すげえ やっと少しでもJavaに関係ある反応したと思ったら、 誰でも分かる超低レベルの内容を嬉々として答えてる こいつすげえ デーモンスレッドの問題にゴミみたいなキーワードしか並べられない低能が言うなアホカス 何行目か教えてやれよ?ん?どうだ?お前にわかるか? どうした?アホ >https://www.google.com/search?q= スレッド 同期化 可視性 java&oq=スレッド 同期化 可視性 java なんだこれw 全然関係ねーわドアホw 今までアホすぎてわざわざ突っ込まなかったけど こういう糞馬鹿が勘違いして俺の真似してんだよなw 低能糞アホ 消えろマヌケ 中級者以上ならrunnableの実装見りゃすぐにわかるんだけど ID:cFvopTvT ←こういう馬鹿は結局わからんもんだからすぐに同期ガーとかマヌケなこと書くんだよね バカが真似すんなよアホ 少なくとも同期化してないのは一つの問題 while ループの書き方も問題 play の度、毎回 clip を open してるのと、setFramePosition(0) を入れてないから、そもそもリスナが 1回目しか呼ばれてないのが直接の原因 だけど、これだけは言わせてくれ ID:iThMGLi0 こいつは 100% 何ひとつ理解してなくて、どんな回答でも全ての回答に対して間違ってるかのような示唆をする そして技術的なことは一つも言わない、言ったとしても間違えてる 本当に迷惑だから消えてくれ いっとくが、俺はアンロードの事書いたやつじゃねーからなw 自演とかわけわからんこと言ってくんなよ もう答え教えてやるけど clipをクラス変数で共有してるからだ >少なくとも同期化してないのは一つの問題 ソースコードもまともに読めずに思い込みで「同期化してないのが問題!(キリィイイイイイイッ!」とかwww バカの癖に回答側にまわって間違ったことをさも正解のように書く諸悪の根源ガイジ おまえのような糞馬鹿がいるから初心者が余計に沼るんだよドアホ お前みたいアホはもう死ねよカス >play の度、毎回 clip を open してるのと、setFramePosition(0) を入れてないから、そもそもリスナが 1回目しか呼ばれてないのが直接の原因 これも全然関係ねーしwww 糞馬鹿 マジで死んどけガイジ なるほど、オブジェクトを使いまわしてるわけね これで5000回まわしてみたけど再現しなかった for (int i = 0; i < 5000; i++) { new Chime().play(i % 3); } こっちだと再現した Chime chime = new Chime(); for (int i = 0; i < 50; i++) { chime.play(i % 3); } まぁもしこれが答えを誘導するための質問者の自演だとしたら さすがにワイも一本取られたわw ここまでの低能糞馬鹿ガイジを演じられるとか別の意味でかなり有能だからw アホ アンロード君みたいに開き直って 「おまえがおかしいんだ!(ムキッー!」 って言ってもええんやで? 糞馬鹿ガイジの ID:cFvopTvT 君?ん?どうした?ん?? playのたびにclip変数が上書きされるから clip.close()が呼ばれないってことかの? >ID:iThMGLi0 こいつは 100% 何ひとつ理解してなくて 特大ブーメラン凄いですねぇ・・・ホントw 質問者は何でclipを共有するとスレッド残るのかこいつに教えてもらったら?w どうだ?教えられるかカス?ん? まず正しい回答してやっても礼の一つもないんだよねこういう奴って ほんと舐めてるよね 礼も言わずに次々質問してんのなw おまえも死んどけゴミ 二度とくるなアホ アンロード君 NotClassFound君 同期化君 キチガイほら吹き3人衆 息を吐くように嘘を教えるとかおっそろしいでホンマ >>734 一応だけどクラス変数はインスタンスを作らなくても使用できる変数で clipはインスタンス変数というのが適当だよ 君の書き込みからはたまに知性が垣間見れるから多分書き間違っただけだろうけど 初心者スレなんで真に受ける人がいるかもしれないから一応 データ競合があるのは事実でその辺りも含めてこのソースをどう修正するかは 腕の見せどころではあるね >一応だけどクラス変数はインスタンスを作らなくても使用できる変数で はい、アホ おまえさぁ、アホのくせになんでレスつけるの?アンロード君か? 何が「このソースをどう修正するかは腕の見せどころではあるね!(キリッ!!!」 だよアホ 1分で終わるわアホ ほんまキチガイ糞馬鹿ガイジの巣窟やな >>748 どこがアホ? クラス変数とインスタンス変数は違うよね 同じだと思ってるん? どうなのん? 違う、こいつ ID:iThMGLi0 の言ってることが間違い 毎回インスタンス作っても出来るけど、何回も再生するのに何回もインスタンス作って open して play するのは適当じゃない 一回 open して、特に小さい音声ファイルの場合は、ロード1回したら使い回さないと、再生はじめが遅くなるしパフォーマンスは悪い そもそもこれは1度 new して初期化したら 使い回すっていうそういう設計のクラスでしょ クラス変数とインスタンス変数の違いも知らない人間の言う言葉を信じてはいけない 初心者未満はもう文章書くのやめよう な? もう書いてることの全てが間違ってるからさ 入門書1億万回読めやカス >>751 クラス変数とインスタンス変数は違うよね 同じだと思ってるん? どうなのん? ほらね、技術的なことを書いてボロが出たら関係ないこと言い始めたでしょ 上のレス読んでてもこいつずっとこう バカだから180℃間違った解釈でギャーギャー「俺が正しいんだ!(キリィイイイ!!」って喚いてんだよね ほんと死んでくれゴミ 二度と回答するなアホ >>754 入門書1億万回読んだならわかると思うんだけどクラス変数とインスタンス変数は違うよね? 見事にアンロード君と同し病気発症しててワロタwwwww ほんまモンスターガイジだなコイツw バカ通りこしてキモすぎるからマジで死ねってw アホ >>756 クラス変数とインスタンス変数は違うよね 同じだと思ってるん? どうなのん? こんな感じでソースコードをまともに読めない初心者未満のガイジに 正しい答えを教えても全く意味がないことがよくわかる良い例だな 何も成長しないんだよ THE モンスター低能ガイジ >>758 クラス変数とインスタンス変数は違うよね 同じだと思ってるん? どうなのん? さすがにインスタンス変数の意味でクラス変数って言っちゃうとか擁護のしようがない とりあえずそこのところは俺も気になるから徹底的に追求してあげてくれ こういう風に関係ない罵詈雑言書き連ねてても、今後このスレにいる以上はずっと追求し続けてあげてくれ スコープが違うだけで実態がなくても使えることにはならない エラー出ても使えるって言い張るガイジなら勝手にどうぞ くだらねーことを何回も書いてホントきしょくわるいね アホ 君はあだ名つけるの好きみたいだからそれに倣うけど、君の名前はクラス変数君ってことでいい? >>761 クラス変数とインスタンス変数は違うよね? >そもそもこれは1度 new して初期化したら 使い回すっていうそういう設計のクラスでしょ これもソースコード読めな過ぎの馬鹿文章 ほんとおまえさぁ、ただのほら吹き糞馬鹿なんだからもう意地張ったり背伸びするのやめたら?w 全てが間違っててアホなんだよお前のレスはw アホ >>762 もうこのスレのアイドルだから姫でもいんじゃないかな 別に毎回newしなくてもエラーでないしw ほんとソースコード読めないアホ 消えろゴミ 間違えてる間違えてるってそればっかだけど、間違えてるなら何が間違えてるか指摘しなさいよ クラス変数とインスタンス変数の違いは丁寧に教えてもらってでしょ君 お礼言わない人嫌いだったよね? ちゃんとお礼言いなよ とりあえずホラ吹きガイジのお前は二度と回答側にまわらないように 一生ROMってろ >>766 あなたの指摘は、 > clip を "クラス変数www" で共有してるから って言うものでしょ? clip を共有しないということは、毎回 Clip を new することに他ならないじゃないですか 共有せずに、毎回 new もせずに、clip を使って再生する方法を後学のために教えてもらえますか? さすがに、クラス変数とインスタンス変数の違いも知らない初心者とバレた以上、その逃げ方は滑稽でしかない 聖者ワイ「これこれはこうだからこうなる。わかったか池沼よ?」 池沼(ID:cFvopTvT)「うるせー!俺が正しいんだ!ボケ!」 池沼(ID:cFvopTvT)「後学のために教えてもらえますか?(ブヒッw」 聖者ワイ「消えろゴミ」 逃げるも糞もおまえは馬鹿すぎ&ほら吹き&無様&低能 ソースコードまともに読めるようになってから喚け低能糞ゴミキッズ きしょくわりぃ >> 753 以下ループで そういう中身のない罵詈雑言系はもう良いっす 己の醜態を関係ないネタで勝手に知らない扱いして 喚き散らしてなかったことにしようとしてる無様な姿は酷すぎるし レスせずに消えればいいものを アンロード君といいこの手の醜態晒すキチガイはどういう脳みそしてんだろうな マジで さすがにきしょすぎて引くわ 今回はお前があまりに頭が悪すぎる知ったかほら吹きレスをつけるから 間接的に質問者に答えを教えることになったが おまえみたいゴミに教えることなんて一つもないよ 脳みそ腐ってんのか? ID:iThMGLi0には誰も味方がいない… リアルでも孤立してるんだろうな こんな奴に友人が出来るわけがない 初心者入門者はこのスレ以外で質問することを強くお勧めしたい 味方も糞も嘘つき同士で仲良くしてるだけやんw ID変えて一生懸命ワイを叩いてるけどさw ワイがいなかったら質問者はこいつ等の嘘に悩まされて解決策は一生わからないままだったんやで おっそろしい話だ >>696 Clipはスレッドセーフなんだけど AudioInputStreamがスレッドセーフじゃないっぽい 再生ごとにAudioInputStreamのインスタンスを作成すればよい STOPの待ち合わせはラッチを使うと簡単かつ安全 https://ideone.com/04E4rq Clipを使い回すならこんな感じでいんじゃないかな https://ideone.com/ieK4ND Clip は、再生前に音声データを全部ロードしてから使うクラスで、 インスタンスを使い回さず、再生前に再生時間の取得とかが必要ないなら、 SourceDataLine を使ってリアルタイムにストリーム化した再生をしたほうが良い 「AudioInputStream がスレッドセーフじゃないっぽい」というのは本来はあまり関係なくて、それを使ってる Clip が実装内で同期化してるなら問題ない 質問者のコードは何故か毎回 open してるからあれだけど、Clipを使う場合、open時に受け渡すだけの AudioInputStream は、Clip の中以外で複数スレッドでは使わないでしょうし Clip の API見たらスレッドセーフと明示されてるわけじゃなくて、本当は Clip の実装クラスが同期化してるかによるけど >>778 の下の方のソースコードで問題ないと思う 細かいことをいえば、 Clip[] clips = { create("C:\\Users\\a\\Desktop\\work\\decision1.wav"), create("C:\\Users\\a\\Desktop\\work\\decision2.wav"), create("C:\\Users\\a\\Desktop\\work\\decision3.wav") }; この変数自体が同期化されてないとか ロード、アンロード、ストリーム化した再生、同期化、複数同時再生とやってったコードあるけど、ここには書けない 補足) >>778 の下の方のソースコードで問題ないと思う といったけど、再生終わる前に再生すると壊れるから、やっぱりちゃんと同期化は必要かな >>780 なるほどね clipsの変数が同期化されてないのは可視性の話? スレッドが起動するときに同期化は行われるはず >>781 そのへんClipがやってくれないん? 困ります! >>781 final でない変数を複数スレッドで使う場合は常に同期化が必要 > スレッドが起動するときに同期化は行われるはず たしかに、実質的に final なら動作上は問題ない、だから「細かいこと」 でも、final にしてないなら作法上やっぱり同期化は必要(final Clip[] clips でもダメだからね) 自分だけが見て、自分だけが書くプログラムなら好きにすればいいよ >>783 ごめんね、やっぱり問題なかったわ… 再生中に再生しようとすると、無視されるだけだった >>778 どうも、昨日の質問者です。わざわざプログラムまで書いて頂いてありがとうございます。下の方ですが、これを Chime chime = new Chime(); chime.play(0); と使えば完璧ですね。ですが、 new Chime().play(0); にすると Direct Clip が再生した回数分増えていかないですか? そして上の方ですが、0.2秒間隔で500回再生してみると、通常は スレッド[Thread-124](実行中) デーモンスレッド[Direct Clip](実行中) スレッド[Thread-125](実行中) デーモンスレッド[Direct Clip](実行中) スレッド[Thread-126](実行中) デーモンスレッド[Direct Clip](実行中) というようにデバッグビューに表示され、音が鳴ります。しかし時々 スレッド[Thread-124](実行中) スレッド[Thread-125](実行中) スレッド[Thread-126](実行中) デーモンスレッド[Direct Clip](実行中) デーモンスレッド[Direct Clip](実行中) デーモンスレッド[Direct Clip](実行中) 表示がこのようになり、その間音が止まります。そしてまた元に戻ったところでたまった音が一気に鳴るような現象が起きます。 そしてこの現象が起きる度に消えない Direct Clip が一つ増えます。この現象が出ているのはうちだけでしょうか? >>784 finalにするとコンストラクタの処理が完了した時点での可視性が保証されるってことでしょ 一方でスレッドが起動するときにもhappens-beforeのセマンティクスは適用されるから同期の目的が可視性ならfinalつけなくても問題ないと思ったんよ >>787 > finalにするとコンストラクタの処理が完了した時点での可視性が保証されるってことでしょ 違う、そういう意味で final の場合は同期が必要ないって言ってるんじゃない final にすると書き換えられないから、一度可視になればそのままの値であることがずっと保証されてる 一方、Clip[] clips の場合は final じゃないから、値が更新されたらその時点で同期が保証されない 作法としては、final じゃない、複数スレッドに渡って使用する変数は常に同期は必要 >>788 そういう意味ね 状態変えられたらどうしようもないし 変数に再代入してるところないし 上のコードは同期取れてるけど一般論としてはということね なるほどね >>786 ループのたびにインスタンス作るやり方だと5000回 回してもうちのPCでは再現しなかったんよね 条件が足りてないのかもしれないけど >>790 うちの環境のせいかもしれませんね。これ以上は諦めることにします。 >>781 そこにfinal付けるかどうかこの例だと全くどうでもいい。 配列・オブジェクトに対するfinalとは? もちろんfinalを可能な限り付けることは推奨だけど。 >>792 > final Clip[] clips でもダメだからね ってちゃんと書いてるからね >>786 単にそのライブラリが、非同期・マルチスレッドに対応していないのだろう。 対応していない機能を使うから、バグるのでは? ライブラリには、シングルトンみたいな単一オブジェクト・資源を使っているものがあって、 それを共有できないものが多い だから、ライブラリの説明書には、 このライブラリはマルチスレッドでは使えない、などと書いてあるものが多い 複数の効果音を同時に使えるライブラリなどは、特殊なんだと思う。 Windows だけとか、OS を限定される OSS・Linux 系のライブラリでは、マザーボード上のチップ内の特殊なネイティブ機能は使えないのでは? 普通これらでは、ハイバネートから戻れないとか、電源機能などもまともに動かないだろ ヤマハなどの音源チップと、ライブラリのAPI が、バージョン違いで一致しないとか 基本、マザーボード上のチップは、Windows 限定だろ。 OSS・Linux 系のライブラリでは、正常に動くかどうか分からない まーた頭悪い奴等同士でグダグダ交換日記してるよ ほんとキチガイやなこいつ等 まとめて逝って良し まぁ一番イラつくのは全てが他力本願の頭のイカれた質問者だけどさ やってること同じなのにちょっとデバッグウィンドウの表示ちがうだけで 「〇〇じゃないですか!?なんでですか!?」って バカかとアホかと 少しはテメーで考えろボケカス ほんとこういうのに答え教えても何の意味も価値も成長もないんだわ >>786 >>778 のChime2(後者の実装)をnew Chime2().play(i)で100回とか呼んだ場合ですよね? うちでもDirect Clipのdaemon threadが増殖しますよ。 実行環境にもよるのかもしれませんけど、 Direct ClipスレッドはClip.open(ais)で生成されて、Clip.close()後に終了するようです。 Chime2ではclip.close()が呼ばれないのでスレッドが残るのでしょう。 (おお、やっと書き込めた...why?) (続き) 778の前者の実装(CountDownLatchを使った方)は、 try-with-resources文でclip.close()が暗黙に呼ばれるので chimeインスタンスを使いまわしても、new Chimeを繰り返してもスレッドは増殖しないですね。 確認した環境: AdoptOpenJDK 12.0.1+12, 64bit Server VM (Hotspot) (オーディオデータは C:\Windows\Media\notify.wav 等) $ java --version openjdk 12.0.1 2019-04-16 OpenJDK Runtime Environment AdoptOpenJDK (build 12.0.1+12) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 12.0.1+12, mixed mode, sharing) 漏れらは、動かないゲームエンジンとか知ってるから、音なんて出ない方が多いぐらいw Pixi.js をコアにした、Phaser は音が出るらしいとか、そういう噂で決める 大手のブラウザみたいに、Windows 用を別に作っているものは、半分ぐらいは動くけど、 OSS・Linux 系のライブラリでは、ソースコードを書いてるだけだから、 それをWindows ネイティブの機械語に変換した場合に、動くとは限らない 無線LAN でも、半分は動かない。 各メーカーで、ドライバーを作っていれば動くけど msys2/mingw で、Windows 用にコンパイルしても、互換性が低い。 WSL の方が、MS が作っているから、互換性が高い ヤマハが、Java・OSS 向けのドライバーを作っていれば動くけど、まさか作っていないだろ >>802 解決しました。コンパイラのバージョンが1.8になってました。 Eclipseを最新のものにしていないせいか11までしか使えないのですが、それにしたら症状が消えました。 ありがとうございました。 >>804 解決してよかったですね。 ただ、その報告では結局何をどう変更して解決したのかこちらは分からないです。 個人的には Clip.close() を呼ばなくても大丈夫な場合/環境があるのか気になります。 >>806 >>778 の上のプログラム、CountDownLatchを使った方ですね。それを500回 new した時に その時々によりますがDirect Clip が3つから6、7個くらい残るという症状でした。 で、それを入れていたプロジェクトが使うコンパイラのバージョンを1.8から11に上げたらきれいに直ってしまったということです。 プログラムの方は何もいじらずそのままです。 >>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を丹念にチェックしたら、どこかに載っているかもしれません。 そもそも説明になってなさすぎる まともな文章書けないガイジはレスすんのやめろ マジキチ ■ Java 質問スレのググれカス君とは 質問と回答に対して罵倒を続ける荒らし 罵倒はワンパターンで、ググれカス、ゴミ、馬鹿、キチガイ、低能、チョンなどを多用します プログラミングの基礎知識がないため、技術的な事はほとんど言いません 過去の発言でクラス変数とインスタンス変数を勘違いしていたり、基本的な事も理解できていないことが判明しています どんな回答がついてもそれが間違いだと主張しますが、根拠は示しません あなたの質問についた回答が正しいかどうかは自分で判断して下さい 彼は自分に対する批判は全部自演だと思っているようなので、構うだけ無駄です 図星突かれたらすぐ顔真っ赤にして捏造する癖やめたほうがいいぞ低能ゴミカス アホ 説明になってなさすぎる (自分も説明は出来ない) ってパターン多すぎてネタ化してる ロック取ってループで条件チェックはマルチスレッドの基本だけれどそれやってなかったんだなー標準ライブラリにもバグが潜んでるものなんだなー ゲームエンジンとか、まともに音が出る方が少ないw それに、色々なブラウザで動かないから、Chrome 限定にする Pixi.js をコアにした、Phaser は音が出るらしいとか、 そういう噂ばっかりを集めて、皆で動くエンジンへ移動するw 開発者は、動かないエンジンを修理するよりも、 皆で動くエンジンへ移動するw ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる