回答編集履歴
1
コメントや他の回答についてまとめ追記
test
CHANGED
|
@@ -1,3 +1,164 @@
|
|
|
1
|
+
# 05/30 01:15追記
|
|
2
|
+
解決済みになっていますが、本当に正しいのかちょっと疑わしいので情報をまとめておきます。
|
|
3
|
+
|
|
4
|
+
長々と書いてしまいましたが質問者さんや同様の疑問を抱いてこの質問に辿り着いた方の一助になれば…ということで。
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
## 勝手な用語の定義
|
|
8
|
+
|
|
9
|
+
* 広義のデッドロック
|
|
10
|
+
複数の共有リソースを用いた処理において、複数のスレッド/プロセスが互いにリソースの解放待ちでそれ以上処理を進められなくなる状態
|
|
11
|
+
* 狭義のデッドロック
|
|
12
|
+
広義のデッドロックのうち、言語特有のロック機能を用いているもの(Javaのsynchronized等)
|
|
13
|
+
|
|
14
|
+
※この記事のために私が勝手に導入した用語です
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
## 「徹底攻略Java SE 11 Gold問題集」の修正内容
|
|
18
|
+
|
|
19
|
+
以降、「徹底攻略Java SE 11 Gold問題集」のことを単に「書籍」と呼びます。
|
|
20
|
+
|
|
21
|
+
* 誤植修正前 (2021年9月21日 初版)
|
|
22
|
+
* コード
|
|
23
|
+
`t1.execute(s1, s2);`
|
|
24
|
+
`t2.execute(s1, s2);`
|
|
25
|
+
* 書籍の回答
|
|
26
|
+
『デッドロックの可能性がある』
|
|
27
|
+
* 誤植修正後 (2023年11月1日 第1版第5刷)
|
|
28
|
+
* コード
|
|
29
|
+
`t1.execute(s1, s2);`
|
|
30
|
+
`t2.execute(s2, s1);`
|
|
31
|
+
* 書籍の回答
|
|
32
|
+
『デッドロックの可能性がある』
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
※誤植修正前のコードでは、実際にはデッドロックは発生しない
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
(質問者さんの引用＆ikedasさんの書き込みより)
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
## 私の考える正しい解釈
|
|
42
|
+
|
|
43
|
+
一般的にデッドロックと言えば、広義のデッドロックを指すと私は考えています。
|
|
44
|
+
|
|
45
|
+
書籍でも同じく広義のデッドロックの意図で問題を作成したところ
|
|
46
|
+
誤植修正前にはコードの一部に誤りがあり、誤植修正後はコードと回答が一致するようになった…と考えています。
|
|
47
|
+
|
|
48
|
+
現時点でベストアンサーになっているjimbeさんの回答は、『狭義のデッドロックが起こらない』という趣旨なのか、
|
|
49
|
+
あくまで書籍の誤植修正前のコードについて論じているだけなのか判断が付きませんでした。
|
|
50
|
+
|
|
51
|
+
ただ、質問者さんは狭義のデッドロックについてだと解釈されているように思われます。
|
|
52
|
+
質問者さんが私の回答へのコメントで「デッドロックではなく、ただの無限ループ」と発言されていますが
|
|
53
|
+
実際は「狭義のデッドロックではないが、無限ループによる広義のデッドロック」という解釈が正しいと私は考えています。
|
|
54
|
+
|
|
55
|
+
|
|
56
|
+
## 一般的な定義ではなく、Java Gold試験におけるデッドロックの定義について
|
|
57
|
+
仮にJava Gold試験でのデッドロックの定義が狭義のデッドロックのことであるなら（例えばoracleの試験要綱等に記載があれば）
|
|
58
|
+
少なくとも試験においては一般的な（と私が考えている）定義ではなく、そちらに合わせて回答すべきです……が
|
|
59
|
+
そうすると書籍の方が誤った定義の出題をしていることになってしまいます。
|
|
60
|
+
|
|
61
|
+
試験のための知識だとしても、出題側がどういう意図なのか試験要綱や試験のための参考書の記述を確認してみてほしいです。
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
## コードの書き方の問題
|
|
66
|
+
今回のコードはあまり普通の書き方をされていないので、それも混乱の原因になったとは思います。
|
|
67
|
+
解放待ちにウェイトも付けず何も処理を入れないならば素直に`synchronized`で待てばよくて、空の無限ループは用いるべきではありません。
|
|
68
|
+
また質問者さんが引用されているコードが一字一句そのままであるなら、実用コードであれば存在するはずの共有リソースを用いた処理について何も（省略の旨のコメントすら）書かれておらず
|
|
69
|
+
実際にコードを走らせて検証してもおそらくタイミング問題でデッドロックが再現しにくいのではないかと思われます。
|
|
70
|
+
|
|
71
|
+
資格試験で理解度を問うためにわざと分かりにくいコードの書き方をしているのかな？くらいの解釈だったので特に言及しませでしたが……
|
|
72
|
+
実際のデッドロックを論じる検証コードであれば、普通は実処理を模したsleepを入れたり、確認のための標準出力処理を入れたりします。
|
|
73
|
+
デッドロックの再現はタイミング問題なので「何度実行してみても再現しない」というのもよくあり、そこでこのsleepを増減させたり標準出力をなくしたりと色々工夫して検証することになります。
|
|
74
|
+
|
|
75
|
+
そういう事情もあるので、たまたま実行した時にデッドロックが発生しないから「コードに問題がない」と短絡的に考えるのではなく、「デッドロックが発生しうる構造かどうか」を考える力が必要となります。
|
|
76
|
+
今回の誤植修正後のようなコードを対象にする場合などは、狭義のデッドロックか否かを論じても実用的にはとくに意味がないと考えています。
|
|
77
|
+
（「デッドロックは発生しないがリソースの取り合いで処理が終了しない構造なので修正しなければならない」みたいな意味の分からない会話が生まれてしまいます）
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
|
|
81
|
+
## 件のコードでの広義のデッドロック発生について
|
|
82
|
+
|
|
83
|
+
誤植修正前の説明は05/26時点で書いたので
|
|
84
|
+
誤植修正後のコードについて
|
|
85
|
+
|
|
86
|
+
`t1.execute(s1, s2);`
|
|
87
|
+
`t2.execute(s2, s1);`
|
|
88
|
+
の場合の実行イメージについて
|
|
89
|
+
以下のようなタイミングで実行されると広義のデッドロックが再現できます。
|
|
90
|
+
|
|
91
|
+
1. 初期状態 `s1.test == null` かつ `s2.test == null`
|
|
92
|
+
1. 2スレッドで(ほぼ)同時に最初の while 文を実行
|
|
93
|
+
1. t1 のスレッドでループ判定の `!samples[0].hello(this)` を実行
|
|
94
|
+
つまり s1.hello(t1) がtrueを返し、whileループ終了
|
|
95
|
+
1. t2 のスレッドでループ判定の `!samples[0].hello(this)` を実行
|
|
96
|
+
つまり s2.hello(t2) がtrueを返し、whileループ終了
|
|
97
|
+
※この時点で何も競合していない
|
|
98
|
+
1. 状態 `s1.test == t1` かつ `s2.test == t2`
|
|
99
|
+
1. 2スレッドでほぼ同時に次の while 文を実行
|
|
100
|
+
1. t1 のスレッドでループ判定の `!samples[1].hello(this)` を実行
|
|
101
|
+
つまり s2.hello(t1) がfalseを返し、whileループ継続 (無限に終わらない)
|
|
102
|
+
1. t2 のスレッドでループ判定の `!samples[1].hello(this)` を実行
|
|
103
|
+
つまり s2.hello(t2) がfalseを返し、whileループ継続 (無限に終わらない)
|
|
104
|
+
※メソッド呼び出しのsynchronizedで止まるわけではないが、t1,t2いずれもs1,s2という2つのリソースを占有できずに永遠に処理が進まない
|
|
105
|
+
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+
## おまけ1
|
|
110
|
+
|
|
111
|
+
件のコードでのsynchronizedについて一応解説します
|
|
112
|
+
|
|
113
|
+
### Test.executeのsynchronized
|
|
114
|
+
Test.execute についてるsynchronizedは、実際のところ別インスタンスなので意味はありません。
|
|
115
|
+
ミスリードのために付けたのかもしれません。
|
|
116
|
+
|
|
117
|
+
### Sample.hello および Sample.bye のsynchronized
|
|
118
|
+
`s1.hello(t1)` と `s1.hello(t2)` など同時実行されることはありますが、既に論じられている通りこれらが直接デッドロックの原因になるわけではありません。
|
|
119
|
+
ならば意味がないかというとそんなことはなく、アトミック性や可視性を担保するために必須となります。
|
|
120
|
+
|
|
121
|
+
#### アトミック性
|
|
122
|
+
これがないと例えば、
|
|
123
|
+
t1スレッドで`this.test == null`がtrue判定されてから`this.test = test;`が実行される間に、t2スレッドでも`this.test == null`をtrue判定し、
|
|
124
|
+
`s1.test == t1` となった直後に `s1.test == t2` と上書き処理され、2スレッドで同時に s1.hello がtrueを返すような不整合状態が起こりえます。
|
|
125
|
+
|
|
126
|
+
#### 可視性
|
|
127
|
+
これがないと、それぞれのスレッドが最新のデータを見ない可能性があります。
|
|
128
|
+
|
|
129
|
+
例えば
|
|
130
|
+
t1スレッドで `s1.hello(t1)` を実行した結果 `s1.test == t1` の状態になったが
|
|
131
|
+
t2スレッドが最新のデータを読まずにローカルキャッシュの `s1.test == null` をそのまま用いて `s1.hello(t2)` を実行すると不整合状態になりえます。
|
|
132
|
+
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
## おまけ2
|
|
136
|
+
|
|
137
|
+
melianさんが挙げられている記事について
|
|
138
|
+
https://qiita.com/hanohrs/items/d0d3a5288db10b69d2a4#13-%E7%AB%A0-%E5%95%8F%E9%A1%8C-33
|
|
139
|
+
|
|
140
|
+
> 1. スレッド1が s1.hello() を実行し、s1.test が非 null になる
|
|
141
|
+
> 2. スレッド2がスレッド1が書き換えた s1.test を参照し、非 null なので、while ループを抜けられない
|
|
142
|
+
> 3. スレッド1が s1.bye() を実行し、スレッド1では s1.test が null に戻る
|
|
143
|
+
> 4. スレッド2が、s1.test が volatile でないのでスレッド1が更新した値を読むことができず、非 null の値を読み続けて while ループを抜けられない
|
|
144
|
+
|
|
145
|
+
t1：s1.hello を実行
|
|
146
|
+
t2：s2.hello を実行せず s1.hello を実行している (s2.hello を先に実行しているなら 広義のデッドロックで 3.の t1：s1.bye に辿り着けない)
|
|
147
|
+
|
|
148
|
+
…ということで、これは誤植修正前のコードについて論じていると思われ、
|
|
149
|
+
誤った前提（誤植修正前のコードでデッドロックの可能性がある）を元に誤った結論を導き出してしまっています。
|
|
150
|
+
|
|
151
|
+
ちなみに非デーモンスレッドの終了条件やsynchronized内の可視性あたりの勘違いがあるっぽいので
|
|
152
|
+
正直ちゃんと仕様を理解したうえでの推察とかではなく、たんなる想像を書いているのでは？…という気がするのであまり鵜呑みにしない方がよさげです。
|
|
153
|
+
|
|
154
|
+
スレッド終了…… 書籍のコードだとタイミング問題で先に "end" が出力されてからスレッド処理が継続する場合も普通にある。そもそも誤植修正前の場合絶対にデッドロックが起こらないので単に "end"出力→スレッド2つの処理が正常に終了…となったのを『スレッドの終了を待たずに正常終了してしまう』と勘違いしたのかも。
|
|
155
|
+
|
|
156
|
+
synchronized内の可視性…… synchronizedは入る時と出る時にローカルキャッシュを捨てて可視性を担保するので、『スレッド2が、s1.test が volatile でないのでスレッド1が更新した値を読むことができず』はあり得ない。
|
|
157
|
+
|
|
158
|
+
|
|
159
|
+
|
|
160
|
+
|
|
161
|
+
# 以下05/26時点の書き込み
|
|
1
162
|
現状のコードではデッドロックは発生しません。
|
|
2
163
|
|
|
3
164
|
Test.execute はこのコード内ではスレッド2つがそれぞれ１つずつ別のTestインスタンスを占有する形になっているので特に競合は発生しません。
|