viscent/javamtp

《Java多线程编程实战指南（设计模式篇）》源码

javamtp's Issues

ch4.gs 死锁问题

NestedMonitorLockoutExample类中内部类Helper
方法xGuarededMethod 和 方法xStateChanged 是否应该去掉 synchronized
blocker。callWithGuard（ga）内中lock锁，即使lock.wait.但是NestedMonitorLockoutExample对象锁未释放

Add a security policy

Hey there!

I belong to an open source security research community, and a member (@ready-research) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

编译报错缺少io.github.viscent.util.Tools这个类

在io.github.viscent.mtpattern.ch7.pc.exmaple.AttachmentProcessor中使用了io.github.viscent.util.Tools
/workspace/JavaConcurrencyPatternInAction/src/main/java/io/github/viscent/mtpattern/ch7/pc/exmaple/AttachmentProcessor.java:28: 错误: 找不到符号
import io.github.viscent.util.Tools;
^
符号: 类 Tools
位置: 程序包 io.github.viscent.util
/workspace/JavaConcurrencyPatternInAction/src/main/java/io/github/viscent/mtpattern/ch5/tpt/example/SomeService.java:20: 错误: 找不到符号
import io.github.viscent.util.Tools;
^
符号: 类 Tools
位置: 程序包 io.github.viscent.util
/workspace/JavaConcurrencyPatternInAction/src/main/java/io/github/viscent/mtpattern/ch7/pc/exmaple/AttachmentProcessor.java:33: 错误: 找不到符号
Tools
^
符号: 变量 Tools
位置: 类 AttachmentProcessor
/workspace/JavaConcurrencyPatternInAction/src/main/java/io/github/viscent/mtpattern/ch7/pc/exmaple/AttachmentProcessor.java:65: 错误: 找不到符号
Tools.randomPause(100, 80);
^
符号: 变量 Tools
/workspace/JavaConcurrencyPatternInAction/src/main/java/io/github/viscent/mtpattern/ch5/tpt/example/SomeService.java:50: 错误: 找不到符号
Tools.randomPause(100, 50);
^
符号: 变量 Tools
位置: 类 SomeService.Consumer
5 个错误

关于two-phase termination(两阶段终止)代码部分的疑问

文海兄：
看了这个模式的代码后有点疑问。在AlarmAgent#sendAlarm部分，首先判断了terminationToken是否被关闭，然后才将消息入队列，但是这两个操作并不是原子操作。有否可能出现这种情况：当这个判断通过后（没有关闭），在执行插入队列之前，terminationToken被置成关闭，且这个时候消费端刚好把队列里面最后一个消息消费完，在下一次循环的时候由于发现terminationToken被置成关闭且reservation为0，所以直接退出。这个时候再执行之前的插入队列操作，那这种情况下这个消息就会永远在队列里面不会被消费者消费了。