★★Java質問･相談スレッド181★★

**デフォルトの名無しさん** · 2018/02/10(土) 17:49:40.56

プログラミング言語Javaに関する質問スレです。
JavaScript, Ajaxの質問は、ここでは受け付けていません。
Web製作管理　　　 http://pc11.2ch.net/hp/
Webプログラミング http://pc11.2ch.net/php/
をご利用下さい。

よくある質問
・「コマンドまたはファイル名が違います」
　「'javac' は、内部コマンドまたは外部コマンド、
　操作可能なプログラムまたはバッチファイルとして認識されていません。」
　「Exception in thread "main" java.lang.NoClassDefFoundError: 」
　(p)ttp://www.wikiroom.com/java/?path,classpath
・「\12288 は不正な文字です。」
文字リテラル以外で全角スペースは使えません。半角スペースに。
・その他の質問→「APIのjavadoc見ろ」
・String に == は使うな。equals() を使え。※

質問時の心得
・コンパイルエラーか実行時エラーか、エラーではないが意図しない動作なのかはっきりしろ。あとエラーメッセージちゃんと読め。
・前提条件としてOS、開発環境、バージョン、使用フレームワーク等を明記。

前スレ
★★Java質問･相談スレッド180★★
https://mevius.5ch.net/test/read.cgi/tech/1492780397/

**デフォルトの名無しさん** · 2018/10/08(月) 08:58:46.13

まあそれは簡単に言うと
開発時のソースコードはデバッグ出力の行があったりするんだけど
リリース時はデバッグ出力の行を文字列置換で一掃したりする。で、もし
if(...)
debugLog(...);

こういう行があったとして、debugLog(...);を置換で削除したら、エラーになる。
if(...){
debugLog(...);
}
これは置換しても大丈夫。

だから、括弧無しは処理部分を置換する事があるか、による
経験上置換するのはデバッグ系コードだけ

**デフォルトの名無しさん** · 2018/10/08(月) 09:13:02.08

書き換えるつもりがない1行のはカッコ省略で書くと読みやすい、あとあと置換するdebugLog(…)とかは消したときに空のブロックになるように{}書いとく、ってことでしょうか？

**デフォルトの名無しさん** · 2018/10/08(月) 09:51:13.29

>>777
嘘をついてはいけない
デバッグ出力を置換で消す場合は ";" に置き換えれば良いので
{} の有無など関係ない

**デフォルトの名無しさん** · 2018/10/08(月) 09:55:23.16

>>779
それは気付いてなかったｗ

じゃあ括弧無しのデメリットは特に思いつかない

**デフォルトの名無しさん** · 2018/10/08(月) 10:26:38.83

>>774
落ち着け、深呼吸しろ

**デフォルトの名無しさん** · 2018/10/08(月) 11:34:11.42

>>774-776
&&・||の右側に、副作用があったら危険！
副作用とは、何かの状態を変えること

ぱっと見ただけでは、副作用が実行されるかされないのかが、わかりにくい。
右側に、副作用が無ければよいけど

if-else 文なんかより可読性が低いから、誤解しやすい

すべての言語で、言われている。
MISRA-C とか、C言語のルールでも、決められている

**デフォルトの名無しさん** · 2018/10/08(月) 12:02:59.41

副作用があるかもしれないから、という理由なら条件分岐関係無くない？
if(a == null)
return;
if(a.get()<=1)
return;
これでget()呼ぶのも副作用あるかもしれないよね？

**デフォルトの名無しさん** · 2018/10/08(月) 12:20:29.15

>>783
別スレッドによって a が null にされてしまう可能性はあるな。だいたいの場合はそういうスレッドがないか、
またはあると分かっているならロックしてからアクセスするように作るから問題にならないんだろうけど。

**デフォルトの名無しさん** · 2018/10/08(月) 12:26:37.42

ん？こういう理解だけど。参照が渡されてるだけだから
別スレッドが参照を破棄しても関係ないぞ

func1(Object a){
if(a == null)
return;
a.get();//絶対にNPEが起きないマルチスレッド無関係
}
func2(Object a){
a = null;
}

**デフォルトの名無しさん** · 2018/10/08(月) 12:29:19.11

そもそも式の中で副作用のある関数を呼び出すのは危険
&&や||は評価順序が決まってるからまだマシな方でそれ以外の演算子だと評価順序もどうなるかわからんし

**デフォルトの名無しさん** · 2018/10/08(月) 12:32:49.91

でも副作用がある関数はset,write,update,createとか大体それっぽい名前ついてるし
分かるでしょ？
というか情報処理はCRUDだからcreate,update,delete的な名前が必ずついてる

副作用を広くとらえればログ出力も副作用だけど、そういうのは問題無い
getは副作用無しか問題無い副作用のみ、CRUDのRに相当するものだから

だからコーディング規約を作るなら、CRUDを意識させるようなものであるべきで、
真理式でメソッドを呼び出すなとかいうわけわからん規約を作るべきではない
CRUDのうちRのみ呼び出していい、とすべき

**デフォルトの名無しさん** · 2018/10/08(月) 12:37:02.60

ぶっちゃけCUDでも呼び出していい
結局、意味を捉えて間違えないように書けということでしかない
コーディング規約をどういじくってもそこから逃げれるわけじゃない

**デフォルトの名無しさん** · 2018/10/08(月) 12:43:00.19

if (a == 0 || b++ < 1) {
}
こういう書き方をすると一見bが常にインクリメントされるように誤解されやすいからやめとけよって言ってるだけでしょ。

**デフォルトの名無しさん** · 2018/10/08(月) 12:48:22.90

真理式に複数の演算があって、かつ一部に副作用があるとまずい、ってことか

**デフォルトの名無しさん** · 2018/10/08(月) 13:19:09.60

副作用・副作用完了点
評価順序・マクロ

MISRA-C でも、こういう間違いやすい所の、ルールは厳しい

**デフォルトの名無しさん** · 2018/10/08(月) 14:53:07.06

>>785
それならないな。

残るは get() して 1 以下なのを検査した直後に別スレッドによって a の状態が変化して get() が返す値が変わるとかかな。
(そんなの想定の範囲内なら問題ないが)。

**デフォルトの名無しさん** · 2018/10/10(水) 01:35:05.39

adopt openjdkのjdk11リリースされたじゃん。
ttps://adoptopenjdk.net/?variant=openjdk11&jvmVariant=hotspot

LTSだぞ。
ttps://adoptopenjdk.net/support.html?variant=openjdk11&jvmVariant=hotspot

**デフォルトの名無しさん** · 2018/10/12(金) 06:07:22.65

Java 11のJREって無いんですか？

**デフォルトの名無しさん** · 2018/10/12(金) 08:34:35.39

クライアントJREは廃止された
今現在、要JREとして世に出ているアプリをエンドユーザーが実行する公式な方法は存在しない(自己責任で開発環境を入れるしかない)
今後のクライアントサイドJavaアプリの唯一の配布方法は、JDKに含まれるコマンドラインツールを使用して
プラットフォーム毎に実行環境とアプリを同梱した実行可能なパッケージを作ることである
クライアントサイドに関しては、もはやJavaはバイナリ互換ではない
OracleはクライアントサイドJavaを段階的に廃止しようとしており、新規には決して使ってはならない

**デフォルトの名無しさん** · 2018/10/12(金) 09:00:21.36

>>793
当てにならんよこんなの
こいつらはただのビルド屋で、自分達でソースに手を入れる体制はない
次のバージョンのOpenJDKがリリースされた後もOpenJDK公式リポジトリの旧バージョンのソースに対してLTS向けのパッチが提供されるかどうかは、
オラクル様の温情次第

**デフォルトの名無しさん** · 2018/10/12(金) 20:45:34.37

>>795
サンクス

**デフォルトの名無しさん** · 2018/10/22(月) 16:04:20.83

何時の間にかvar使えるようになってたな

**デフォルトの名無しさん** · 2018/10/22(月) 23:21:36.65

いないいないvar

**デフォルトの名無しさん** · 2018/10/22(月) 23:32:16.95

Javaに型推論が無いことをディスられると、意識高い系Javaerさん達は
ローカル変数の型もinterfaceにするべきだからそんなもん要らんと上から目線で反論してたけど
梯子外されちゃって哀れだな

**デフォルトの名無しさん** · 2018/10/23(火) 03:01:58.72

これ2じゃなくて1が出力される。何で？
@Test
public void mapObjTest() {
Map<Long, Integer> m = new HashMap<>();
Long key = 1L;
m.put(key, 1);
Integer val = m.get(key);
val++;
System.out.println(m.get(key));
}

**デフォルトの名無しさん** · 2018/10/23(火) 03:05:36.61

悪く言われるけどクライアントサイドについてJRE同梱は良いんじゃない？
もはやファイルサイズは小さな問題だし、JREのバージョン違いでの誤作動を減らせる。
クライアントサイドJavaがそれで悪くなったと思わないけどな、俺は
JavaFXが外されたのは悪くなったと思うけど、でもどうせ同梱する作業するときに入れるんだし
妥当な変化じゃないの？

**デフォルトの名無しさん** · 2018/10/23(火) 05:51:34.87

>>801
val++は↓これと同じ
val = val + 1
変数valに値を代入してる

↓こう書けば値は2になる、value.valueはドット演算子を使ってオブジェクトの状態を変えてる

public class Main {
　public static void main(String[] args) {
　　Map<Integer, Value> map = new HashMap<>();
　　map.put(1, new Value(1));

　　Value value = map.get(1);
　　value.value++;

　　System.out.println(value.value);
　}
}

class Value {
　int value;

　Value(int value) {
　　this.value = value;
　}
}

変数に対する代入と
オブジェクトの状態を変えることとは
異なる操作なんやで

**デフォルトの名無しさん** · 2018/10/23(火) 07:00:55.65

変数への操作か、オブジェクトへの操作かを区別する必要があって

それぞれの違いはこんな感じ
https://light.dotup.org/uploda/light.dotup.org554015.png

**デフォルトの名無しさん** · 2018/10/23(火) 07:55:16.19

>>801
Integerをインクリメントした瞬間に新しくIntegerインスタンスが生成されるからだな

詳しくはオートボクシング、インクリメントとかでググるといい

**デフォルトの名無しさん** · 2018/10/23(火) 08:11:13.69

要するにval++は↓の省略系
val = new Integer(val.intValue()+1)

**デフォルトの名無しさん** · 2018/10/23(火) 09:23:24.20

>>802
悪くはなってないよね
0に何を掛けても0だからな

**デフォルトの名無しさん** · 2018/10/23(火) 09:42:44.32

すごーい

**デフォルトの名無しさん** · 2018/10/23(火) 23:29:12.49

>>802
動的リンクしまくってるからFullJRE前提だわ。

**デフォルトの名無しさん** · 2018/10/25(木) 05:33:58.31

Object#equals()
public boolean equals(Object obj) {
return (this == obj);
}
なんでreturn this == obj;じゃなく括弧で囲ってるの？

**デフォルトの名無しさん** · 2018/10/25(木) 09:55:01.19

囲ってみたい気分だったのだろう

**デフォルトの名無しさん** · 2018/10/25(木) 11:06:47.39

return文に記述された式が複雑なときは括弧で括ったほうがmore readableだから推奨してる人のほうが多いように思うけど、
this == objが複雑かどうかは微妙だね。

でも自分なら括弧つけるかな。
理由は、括弧でくくることで、等式が値を返す数式として使われていることを明示できるから。

**デフォルトの名無しさん** · 2018/10/25(木) 11:34:47.74

Javaの最黎期に書かれたものだろうから、コードスタイルが今の基準からすれば変でもおかしくない
今では一般的には括弧はつけないのが主流だね

**デフォルトの名無しさん** · 2018/10/25(木) 12:09:47.24

最近はアローで書いちゃうから一行だしな

**デフォルトの名無しさん** · 2018/10/25(木) 14:00:36.81

計算がよくわからん時は、まず括弧で囲えって、
今でも教える人がいるからな

**デフォルトの名無しさん** · 2018/10/25(木) 14:21:09.91

かっこいい、かっこわるい？

**デフォルトの名無しさん** · 2018/10/25(木) 18:46:51.45

>>815
演算子の優先順位の話なら不要だと思ってもあえてつけたままにすることはあるな
+ と * とかならいいけどビット演算子とか言語によって違う奴とかもあるしね

**デフォルトの名無しさん** · 2018/10/27(土) 15:01:56.02

javaでaccessdbと接続するようなソフト作ってみたいんですが
フレームワークって必要ですか
ちょっとフレームワーク自体よくわかってないです。
規模は社内で5人くらいで使用します。

**デフォルトの名無しさん** · 2018/10/27(土) 19:11:03.52

検索すれば出てくるけど
ハマることが多そうだからオススメしない
Javaが要件なのかAccessが要件なのかわからんが

**デフォルトの名無しさん** · 2018/10/27(土) 19:15:14.94

>>812
Webで避けて通れないJavaScriptのせいとかもあるな。
JavaScriptのセミコロン省略可能はいまだに嵌る。

**デフォルトの名無しさん** · 2018/10/27(土) 19:16:29.43

Ruby on Rails, Node.js などでは、開発環境では、SQLite を使うけど

**デフォルトの名無しさん** · 2018/10/27(土) 22:29:57.54

>>802
Write once,Run anywhere

配布しようと思ったら環境に応じたJRE添付してやらないといけないんだよね？
根本理念に喧嘩売ってる気がする

**デフォルトの名無しさん** · 2018/10/28(日) 03:09:10.51

>>822
バイナリ互換じゃなくなるけどソースコード互換ではあるので・・・

JavaでGUIアプリ作ってネットで配布する場合、エンドユーザーの環境に依存するの辛いでしょ
むしろJRE同梱したい、と思うのが普通だよ

JRE同梱によるファイルサイズ増加はもはや問題にならないし
どうせJRE同梱作業するなら、その時にJavaFX入れれば良いので、分離されたのも妥当な気がするし
むしろクライアントサイドで進歩してると言っても良いのでは

**デフォルトの名無しさん** · 2018/10/28(日) 03:59:58.74

>JavaでGUIアプリ作ってネットで配布する場合、エンドユーザーの環境に依存するの辛いでしょ
JRE同梱だと回避できて、JARだけだとダメな問題ってどういうのがあるん？
実際にクライアントの環境が異なってたらどうやって提供しようが辛さは一緒におもえる

だいたいJRE同梱なんかされたら何仕込まれてもわからん
サンドボックスのしっかりした仕組みがあるわけじゃなし
そもそもWindowsとかOS側が信用できない

共通のJavaだから信頼感あったのに

**デフォルトの名無しさん** · 2018/10/28(日) 04:08:51.40

今どき.NETですらランタイム同梱する流れだからな

**デフォルトの名無しさん** · 2018/10/28(日) 04:22:29.53

MSはユーザーの個人情報盗みたい側だし

**デフォルトの名無しさん** · 2018/10/28(日) 04:26:41.29

>>824
何言ってるか良く分からんが、JRE同梱すればJREのバージョン違いによる問題が無くなるだろう。
いちいちJREをインストールしてもらう手間も無くなる。
例えば一部のJREはJavaFXを同梱しているが、一部はそうではない。

何仕込まれても、ってのは良く分からんが
スタンドアロンアプリでもセキュリティマネージャーは動くはず

**デフォルトの名無しさん** · 2018/10/28(日) 04:32:23.62

確かにこれまでと比べると、オラクルのサイトからJRE落としてそれで動かしてたのに比べると
アプリ毎にJRE同梱されちゃうとおかしなネイティブ実行ファイルが同梱されてないか、という問題はある

しかし同梱されたプラットフォーム固有の実行ファイルはハッシュ値とかで適切なファイルかを照合できるはず
あとそもそもバイトコード部分でも相当な処理が可能だから、さほどセキュリティリスクが変わると思わない

ネットからプログラムを落とすなら、オープンソースか信頼できる大御所か
これまでと変わらないのでは

**デフォルトの名無しさん** · 2018/10/28(日) 04:34:29.37

>>826
ランタイム同梱の意味わかってる？

**デフォルトの名無しさん** · 2018/10/28(日) 04:36:35.55

問題はJREのバージョンか
たしかに多少の問題はあるが

JRE同梱必須にしたらJavaの目指していた未来と可能性そのものを切り捨てることになる
そうできるってのとそうしなきゃいけないってのはえらい違い

**デフォルトの名無しさん** · 2018/10/28(日) 04:42:15.05

JREを同梱しないと、10年経ったら動かなくなってると思う

クライアントサイドはJRE同梱で作れと強制する事は、そんな悪い事じゃないと思う
そうしないとJavaがバージョンアップしづらい問題もあるから、オラクルはそうしたいんだろう

**デフォルトの名無しさん** · 2018/10/28(日) 04:46:39.09

元々Write once,Test anywhere

って失望されてたじゃ無いか。。。
HTML5も同じだけど、理想と現実は遥かに遠い隔たりがある。

**デフォルトの名無しさん** · 2018/10/28(日) 04:48:23.37

スタティックリンクの肥大した実行ファイルと一緒だよね
Write Onceで全プラットフォームで動いたら開発者としては理想じゃないかな

**デフォルトの名無しさん** · 2018/10/28(日) 04:49:04.83

オラクルはJavaを高速バージョンアップしたいみたいな事も言ってるが、
一連の話は整合性がある
サーバーサイドはエンジニアが管理しててJRE固定できる、
クライアントサイドはJRE同梱。
現状だとJavaから古いAPIを削除したら多くのアプリが動かなくなるから、
移行期間を作ってそのようなアプリが減るのを待つ。
そうしないとJavaに未来が無いという判断は、理解できなくない。

**デフォルトの名無しさん** · 2018/10/28(日) 05:01:48.54

じぶんとこのOracleDBは枯れまくってても平気なくせに

**デフォルトの名無しさん** · 2018/10/28(日) 05:47:19.26

改変されたJREを同梱されたら終わりではないか？

**デフォルトの名無しさん** · 2018/10/28(日) 05:51:56.29

だから、同梱されたファイルのハッシュ値調べればわかるし、
アンチウイルスだって有名な実行ファイルについてハッシュ値を知識として持っておくべき。
オープンソースは誰かが検証すべき。
で、もともとバイトコード部分でも相当な事ができるからセキュリティリスクは変化してない。

**デフォルトの名無しさん** · 2018/10/28(日) 14:47:49.66

クラス変数にもvar使わせてほしいよな
無名クラスにリフレクションで値を代入するフレームワークとかでてきそうだし

class Hoge {
public var xyz = new Object() { int x, y, x };
}

**デフォルトの名無しさん** · 2018/10/28(日) 23:50:32.90

それをやると型を特定するために延々先を辿らなきゃいけなくなるんだ…

**デフォルトの名無しさん** · 2018/10/28(日) 23:52:24.19

Class#forNameで動的リンクするときjlinkとかは依存するクラス検出できないから
結局手動で全部依存関係調べるかfull jre使うかの二択になる。

>>838
互換性が保証できなくなるからやらないだろ。
実行時の型と推論された型は違うから。

**デフォルトの名無しさん** · 2018/10/29(月) 00:01:40.82

というかあれだぞ。
javapackagerなくなったからjava11ではjre同梱したパッケージ作れないし、
なくなったのはpublic jreだけでjreのビルド自体はadopt openjdkがやってるからjre自体はあるぞ。

**デフォルトの名無しさん** · 2018/10/29(月) 00:06:53.79

>>838
コンパイラの仕組み上困難
Javaコンパイラはまず、メンバのシグネチャだけを解析してクラスごとにメンバのお品書きを作る
そして、それが一通り終わった後に各メソッド本体やフィールド代入元の式を解析する
ところがフィールドの型にvarを許してしまうと、お品書きを作る段階でフィールド代入元の式を解析しなきゃいけなくなる
それによりコンパイラのパスが増えてしまうから、コンパイル速度が大きく低下する

**デフォルトの名無しさん** · 2018/10/29(月) 01:24:28.42

>>842
クラスにvar持てるHaxeのコンパイル遅いと感じたこと無いけど
Scalaとかいう言語でものすごく遅くなったという話は聞く

**デフォルトの名無しさん** · 2018/10/29(月) 02:54:18.59

>>841
Java 11でクライアントサイドはどういう扱いになってるの？

**デフォルトの名無しさん** · 2018/10/29(月) 03:02:24.77

新しいパッケージングツールの要件はJavaFX未対応とされている
http://openjdk.java.net/jeps/343

JavaFX由来のパッケージングツールが削除された

じゃあ、JavaFXアプリをエンドユーザーに配布したい場合、どうするの？
現在見つかる情報は、非JavaFXの自己完結型パッケージャ、
JavaFXのビルド方法だけで、JavaFXの自己完結型パッケージャが行方不明なんだけど

**デフォルトの名無しさん** · 2018/10/29(月) 04:02:15.84

https://commons.apache.org/proper/commons-validator/apidocs/org/apache/commons/validator/routines/UrlValidator.html

これはthread safeですか？

**デフォルトの名無しさん** · 2018/10/29(月) 22:22:22.37

アウト、セーフ、よよいのよい

**デフォルトの名無しさん** · 2018/10/29(月) 23:23:48.16

>>844
Java Client Roadmap Update
ttps://www.oracle.com/technetwork/java/javase/javaclientroadmapupdate2018mar-4414431.pdf

>>845
jep343がjavafx対応しないんだからないよ。
でも、javafxはただのライブラリなんだからjep343でほかと同じ扱いでしょ。

**デフォルトの名無しさん** · 2018/10/30(火) 14:22:42.63

public synchronized void method1(){}

こういうメソッドレベルでsynchronizedした場合、
synchronized(this){}ということですか？
つまり他のところでsynchronized(this)が書かれていたら、どちらかが待機になるんでしょうか

**デフォルトの名無しさん** · 2018/10/30(火) 15:22:20.46

>>849
その通り
thisをロックするのはパフォーマンスの低下やデッドロックの原因になるため、現代では一般には悪手とされている
synchronizedがデフォルトでthisをロックするのはJavaがまだオモチャでカジュアルに排他制御してた時代の名残で、
ちゃんと作るなら排他制御には private メンバを使って外に漏らさないようにした方が安全

**デフォルトの名無しさん** · 2018/10/31(水) 12:34:18.73

thisをロックするのとロック専用オブジェクトをロックするのは
性能の違いがあるんですか？

**デフォルトの名無しさん** · 2018/10/31(水) 14:41:22.75

>>851
thisはクラス外からも当然見えているわけで、他のクラスも同じオブジェクトを同時にロックしている可能性がある
どえせ内部的に同期してるんなら他のクラスが同時にアクセスしてくることは何の問題もないはずで、これは完全に無駄なブロックだ
クラス外から見えるオブジェクトをロックするのはパフォーマンスだけではなくてデッドロックの可能性を高める非常に悪い行為

**デフォルトの名無しさん** · 2018/10/31(水) 15:22:21.60

デッドロックの可能性は分かるんですが、
その性能の劣化というのは、クラス外でたまたまロックに使われていた場合、
待機時間が生じるから、ということですか？
待機時間以外に構造的に複雑なオブジェクトをロックすることでの性能劣化はありえますか？

**デフォルトの名無しさん** · 2018/10/31(水) 15:45:06.31

>>853
それはない
ロックはオブジェクトヘッダにロック中であることを示す情報を書き込むだけ

**デフォルトの名無しさん** · 2018/10/31(水) 15:58:04.06

意味不明なエラーで苦しめｗ

**デフォルトの名無しさん** · 2018/10/31(水) 16:17:19.41

ロック可能なのは全部ロックしたら苦しんだ黒歴史・・・

**デフォルトの名無しさん** · 2018/10/31(水) 17:20:43.08

専用オブジェクトでロックしても結局プログラマーが入念にチェックする以外
無い気がするんですが合ってますか？
よく言われてるようなロック順序云々では解決しない気がするんですが

**デフォルトの名無しさん** · 2018/10/31(水) 17:23:06.92

Javaはいつかなくなるんですか

**デフォルトの名無しさん** · 2018/10/31(水) 19:25:31.36

いつか

**デフォルトの名無しさん** · 2018/10/31(水) 19:27:08.55

きっとどこかで生き残る

**デフォルトの名無しさん** · 2018/10/31(水) 19:30:32.81

俺のディスクの上で生き残る

**デフォルトの名無しさん** · 2018/10/31(水) 19:48:34.38

デッドロックと言えば、サーバをまたいだロックを掛けててデッドロックになった時は原因究明が大変だったなあ。

**デフォルトの名無しさん** · 2018/10/31(水) 20:18:06.23

>>857
外に漏らさなければ入念にチェックする範囲がクラス内だけに留まるだろ
外から見えるオブジェクトならそれを触ってる可能性のある範囲全てをチェックしなきゃいけない

**デフォルトの名無しさん** · 2018/10/31(水) 21:04:23.41

>>863
クラスA#method1() method3呼び出し
クラスA#method2()
クラスB#method3() method2呼び出し

この状況でmethod1,3を異なるスレッドが呼び出したらデッドロックになりうるのでは？
クラスA,Bがそれぞれ専用のロックオブジェクトを持っていて
method1,2,3の内部でロックオブジェクトでロックしているとして

**デフォルトの名無しさん** · 2018/10/31(水) 21:13:55.51

そういやJavaVMって実行時にデッドロックを見つけ出す機能はないのかな？
OSのファイルロックだと見つけてくれたりするよな。NFS絡むと無理だけど。
(あ、でも2プロセスでロック掛け合った場合だけかな？)

**デフォルトの名無しさん** · 2018/10/31(水) 21:30:17.03

デッドロックを通知する仕組みはあるようです。JConsole

安全なsynchronizedというものは、そのメソッドがどこから呼び出されているか、
どれを呼び出しているかというような依存関係で決まって、
単純な記述方法で安全性を確保する事はできないのではと思いました。
どのオブジェクトをロックしてもこの問題は残ります。
https://www.jpcert.or.jp/java-rules/lck07-j.html
これなんかもそうですが、ロック順序だけで解決できると考えてしまっていますが、
synchronizedブロック内のロジックが他のメソッドを呼び出している場合、
まだデッドロックが発生する可能性があると思います。
派生していくメソッド呼び出しのどこかにsynchronizedブロックがあれば。
もちろん、多くの場合、プログラムは様々なメソッドを呼び出します。
>>857はこの理解で正しいかという意味です

**デフォルトの名無しさん** · 2018/10/31(水) 21:40:58.89

頑張れぼうやｗ

**デフォルトの名無しさん** · 2018/10/31(水) 22:59:47.53

>>864のケースで仮にAがthisをロックしていたとしたら、B#method3がA#method2を呼ばずともB#method3内で直接または間接的にAのロックを試みただけでデッドロックするだろう。
privateなロックオブジェクトを用いたからといってデッドロックの可能性はゼロにはならないが、thisを使うのに比べれば確実に可能性は低くなる。
あえてリスクの大きくパフォーマンスの低下する方を選択する積極的な理由がない。

**デフォルトの名無しさん** · 2018/10/31(水) 23:05:48.35

>>866
何を言いたいのか理解できないが、どこの誰がどんなタイミングでロックを取りに来ようとも、ロックの順番さえ守ってれば絶対にデッドロックは起こらないよ。

**デフォルトの名無しさん** · 2018/10/31(水) 23:43:17.95

DB などほとんどのアプリでは、デッドロックでタイムアウトする。
絶対に回避できない

ロックする順番は、2プロセスの場合、
プロセスAがX, Y、
プロセスBがY, X

3プロセスの場合、
プロセスAがX, Y、
プロセスBがY, Z、
プロセスCがZ, X

**デフォルトの名無しさん** · 2018/11/01(木) 00:20:30.29

>>870
ロックの順番があべこべなのだからデッドロックするのは当然だろう

**デフォルトの名無しさん** · 2018/11/01(木) 06:39:30.81

>>870
バカにロックを使わせるな
って言う見本

せめて初歩の初歩ぐらい理解してからレスしろよ w

**デフォルトの名無しさん** · 2018/11/01(木) 07:11:11.17

>>869
ロックの順番を守る事ができないということです
ブロック内にメソッド呼び出しがあることは普通です

**デフォルトの名無しさん** · 2018/11/01(木) 07:11:48.43

>>868
＞どのオブジェクトをロックしてもこの問題は残ります。

**デフォルトの名無しさん** · 2018/11/01(木) 07:13:39.94

現在している話は、普通のプログラムにおいてロックの順番を守る妥当な方法は存在しないという話です。
synchronizedブロック内でメソッド呼び出しがあった時点でそうなります。
それに対してロックの順番を守ればいいとかthisをロックしろとか言い続けているのは話が分かっていません。

**デフォルトの名無しさん** · 2018/11/01(木) 07:17:18.61

もう少し分かり易い説明を思いつきました。
ここにある問題は、synchronizedブロックで一旦ロック順序を守ったとしても、
そのブロック内から呼び出されているメソッド及びそこから派生的に呼び出されている全てのメソッドにおいて
synchronziedブロックを使う場合デッドロックが生じうるという問題で、
リファクタリング等において恒久的に懸念が残り続けるという問題です。
これは一時ロック順序を守ったコードを書いても解決しません。