質問編集履歴

3

補足追加

2020/10/12 11:23

投稿

ichiro200555
ichiro200555

スコア2

test CHANGED
File without changes
test CHANGED
@@ -330,6 +330,12 @@
330
330
 
331
331
 
332
332
 
333
+ __以下の記事は、Mutexクラスのlock()のif文をwhile文に修正した状態でプログラムを実行した場合のものです。
334
+
335
+ if文だと、そもそも競合状態になる場合があることがわかりました(quickquipさんの回答参照)。__
336
+
337
+
338
+
333
339
  jdbの表示の読み方が間違っていたようです。jdbのlockコマンドでロックに関する情報を確認したところ、lock()の中を実行中のスレッドは1つしかありませんでした。ロック獲得待ちをしているスレッドでwhereコマンドを実行した時に表示される行番号は、実行しようとしているメソッドの中でjdbがブレークポイントをはれる最初の行番号を表示するようです(「try {」やコメント行にはブレークポイントが設定できない。そのため、その次の行の「if (isLock) {」の行番号が表示される)。
334
340
 
335
341
 

2

jdbの表示の読み方に関する記事を追加

2020/10/12 11:23

投稿

ichiro200555
ichiro200555

スコア2

test CHANGED
File without changes
test CHANGED
@@ -244,9 +244,9 @@
244
244
 
245
245
 
246
246
 
247
- jdbでMutexクラスの「System.out.println("isLock=" + isLock);」の行にブレークポイントをはり、他のスレッドの様子を確認したところ、lock()内に2つのスレッドがいました(以下のjdbのログのスレッド0x1beとスレッド0x1bf)。
247
+ ~~jdbでMutexクラスの「System.out.println("isLock=" + isLock);」の行にブレークポイントをはり、他のスレッドの様子を確認したところ、lock()内に2つのスレッドがいました(以下のjdbのログのスレッド0x1beとスレッド0x1bf)。
248
-
248
+
249
- スレッド0x1beはlock()の「if (isLock) {」の部分を、スレッド0x1bfはlock()の「System.out.println("isLock=" + isLock);」の部分を実行しているようです。
249
+ スレッド0x1beはlock()の「if (isLock) {」の部分を、スレッド0x1bfはlock()の「System.out.println("isLock=" + isLock);」の部分を実行しているようです。~~
250
250
 
251
251
 
252
252
 
@@ -316,10 +316,100 @@
316
316
 
317
317
 
318
318
 
319
+ ~~
320
+
319
321
  lock()の中に2つスレッドがいて、正常にロックを実装できていないことが競合が起きている原因だと思いますが、なぜsynchronizedメソッドの中に同時に複数のスレッドが入れるのかがわかりません。
320
322
 
321
323
  新しくlock()を呼んだスレッドはもちろん、notify()によってウェイトセットから出てきたスレッドも、synchronizedによるロックの獲得待ちをするため、lock()には同時に1つのスレッドしか入れない認識です。
322
324
 
325
+ ~~
326
+
327
+
328
+
329
+ **2020.10.12追加**
330
+
331
+
332
+
333
+ jdbの表示の読み方が間違っていたようです。jdbのlockコマンドでロックに関する情報を確認したところ、lock()の中を実行中のスレッドは1つしかありませんでした。ロック獲得待ちをしているスレッドでwhereコマンドを実行した時に表示される行番号は、実行しようとしているメソッドの中でjdbがブレークポイントをはれる最初の行番号を表示するようです(「try {」やコメント行にはブレークポイントが設定できない。そのため、その次の行の「if (isLock) {」の行番号が表示される)。
334
+
335
+
336
+
337
+ ```
338
+
339
+ Thread-0[1] threads
340
+
341
+ グループsystem:
342
+
343
+ (java.lang.ref.Reference$ReferenceHandler)0x173 Reference Handlerは実行中です
344
+
345
+ (java.lang.ref.Finalizer$FinalizerThread)0x174 Finalizer は条件を待機中です
346
+
347
+ (java.lang.Thread)0x175 Signal Dispatcherは実行中です
348
+
349
+ グループmain:
350
+
351
+ (UserThread)0x1be Thread-0 は実行中です(ブレークポイント)
352
+
353
+ (UserThread)0x1bf Thread-1 はモニター内で待機中です
354
+
355
+ (UserThread)0x1c1 Thread-2 はモニター内で待機中です
356
+
357
+ (java.lang.Thread)0x1c6 DestroyJavaVM は実行中です
358
+
359
+ グループInnocuousThreadGroup:
360
+
361
+ (jdk.internal.misc.InnocuousThread)0x1a2 Common-Cleaner は条件を待機中です
362
+
363
+ Thread-0[1] where
364
+
365
+ [1] Mutex.lock (Mutex.java:10)
366
+
367
+ [2] Gate.pass (Gate.java:9)
368
+
369
+ [3] UserThread.run (UserThread.java:16)
370
+
371
+ Thread-0[1] thread 0x1bf
372
+
373
+ Thread-1[1] where
374
+
375
+ [1] Mutex.lock (Mutex.java:8)
376
+
377
+ [2] Gate.pass (Gate.java:9)
378
+
379
+ [3] UserThread.run (UserThread.java:16)
380
+
381
+ Thread-1[1] thread 0x1c1
382
+
383
+ Thread-2[1] where
384
+
385
+ [1] Mutex.lock (Mutex.java:8)
386
+
387
+ [2] Gate.pass (Gate.java:9)
388
+
389
+ [3] UserThread.run (UserThread.java:16)
390
+
391
+
392
+
393
+ // lockコマンドでthis(lock()がロックする時に使うインスタンス)のロックの情報を表示してやると、
394
+
395
+ // 実行中のスレッド(ロックを獲得しているスレッド)はThread-0のみで、Thread-1とThread-2は
396
+
397
+ // ロック獲得待ちであることがわかる。
398
+
399
+ Thread-2[1] lock this
400
+
401
+ com.sun.tools.example.debug.expr.ParseException: Unable to complete expression. Thread not suspended for method invoke
402
+
403
+ 所有者: Thread-0、エントリ数: 1
404
+
405
+ スレッドを待機中: Thread-1
406
+
407
+ スレッドを待機中: Thread-2
408
+
409
+ Thread-2[1]
410
+
411
+ ```
412
+
323
413
 
324
414
 
325
415
  ### 補足情報(FW/ツールのバージョンなど)

1

OSの情報を追加しました

2020/10/12 11:15

投稿

ichiro200555
ichiro200555

スコア2

test CHANGED
File without changes
test CHANGED
@@ -324,7 +324,11 @@
324
324
 
325
325
  ### 補足情報(FW/ツールのバージョンなど)
326
326
 
327
-
327
+ - OS
328
+
329
+ macOS Catalina バージョン10.15.7
330
+
331
+ - Javaのバージョン
328
332
 
329
333
  ```
330
334