REJAVA / LEARNING NOTES
学习小结：先问清楚规则管到哪里
从锁对象、任务接纳与共享额度的理解变化中，整理三个检查习惯。
根据第 4、5 课真实交流整理；不是逐字稿
本次更新说明
- 依据已有问答整理理解转折与复习方法。
这篇小结来自第 4、5 课已保存的真实问答。保留理解发生变化的地方，便于下一次遇到相似代码时检查自己的推理。
从变量名，转向实际对象
讨论 synchronized（内置同步关键字）时，曾把锁的单位理解成变量。后来明确：变量保存的是引用，要沿着引用判断它指向哪个对象。
两个变量指向同一个对象，仍可能竞争同一个 monitor（监视器）；同名变量指向不同对象，也不能据此认定是同一把锁。
可以养成一个检查习惯：先标出锁对象，再判断哪些访问遵守同锁协议。方法名相同、代码写在一起，都不能替代这一步。
从“有没有空闲的人”，转向接纳规则
讨论 thread pool（线程池）时，曾认为提交工作应先找空闲执行者。但 ThreadPoolExecutor（线程池执行器）的正常接纳流程先检查当前执行者数量是否低于 corePoolSize（核心线程数），低于时优先尝试创建。
这里的当前数量包含忙碌和空闲的执行者。这个例子提醒我们：符合生活直觉的安排，不一定就是接口的实际规则。先把条件按执行顺序列出来，再推演具体输入。
从一个应用，转向共享额度
讨论两个应用各允许10个 concurrent requests（并发请求）时，最初没有把两边数量合起来。若下游给整个系统的共享上限是10，两边各放行10就可能达到20。
随后也发现了固定各分5个的限制：一边空闲时，另一边不能自动用到剩余额度。这是“守住总量”和“用好余量”两个不同问题。
遇到限制时，先写清楚它约束哪个范围：一次操作、一个应用，还是整个系统。范围没有说清楚，就容易把局部正确推广成整体正确。