40 | 运用学过的设计原则和思想完善之前讲的性能计数器项目（下）

设计模式_40: # 作业 导致多个线程的重复统计。 办法：加入进程内的全局变量(注意多线程同步问题)。 # 感想 我个人是Android工程师，客户端的开发默认就要思考一个问题：方法重复调用时(如多次点击某个按钮等)逻辑是否还正常。 25，26，39，40这四节课边听边读反复了好几遍了，因为目的是掌握该掌握的东西，而不是简单地打个卡，所以整个春节期间就卡在这四节课的重复中了，不停地循环听。。。 也有好处：我反倒对这几节内容非常熟悉了，有两点感受较深： 1> 方法论：分清楚 *功能性需求* 与 *非功能型需求* 之前是想到什么注意什么，往往做不到穷举。 2> 一步一步地重构，其实解决的是自信问题： 做事要先解决思想问题，也就是心理问题： - 没有人能够一步到位地完美解决问题，优秀的代码是演进的，也就是说，代码结构不完美的状态是跳不过去的。 - 我们始终聚焦在解决问题上，代码有问题非常正常。 - 我们要带着成就感不断重构代码，而不是带着对自己否定的愧疚感，这非常重要。 - 成就感让你追求卓越，愧疚感只是让你不想犯错(而这是做不到的)。

思考题：startRepeatedReport()多次调用，会启动多个线程，每个线程都会执行统计和输出工作。 想了一种简单的实现方式，将runnable做为成员变量，第一次调用startRepeatedReport()时初始化，若多次调用，判空，返回。 public void startRepeatedReport(long periodInSeconds, long durationInSeconds) { if (runnable != null) { System.out.println("duplicate calls!"); return; } runnable = () -> { long durationInMillis = durationInSeconds * 1000; long endTimeInMillis = System.currentTimeMillis(); long startTimeInMillis = endTimeInMillis - durationInMillis; doReport(startTimeInMillis, endTimeInMillis); }; executor.scheduleAtFixedRate(runnable, 0, periodInSeconds, TimeUnit.SECONDS); } 代码放在了：https://github.com/gdhucoder/Algorithms4/tree/master/designpattern/u40

老师能提供课程代码吗？

调用多次可以通过多线程共享的状态变量来解决，CAS或者加锁进行状态的变更。

这两篇实战对自己的感觉就是越来越懵，可能还需要多读读，也不知道是不是跟自己的项目做的很少有原因，前面的理论都还能消化

深入浅出，过瘾。

先回答问题： 1.会导致多余线程做多余的统计和展示。因为每次调用都会起一个异步线程输出统计数据到控制台。这样既会带来额外的性能开销，又会导致统计信息不易阅读。 2.在ConsoleReporter内部维护一个可视字段 started。然后在方法执行时，优先判断该字段是否已经变为true。如果是则不再往下执行。也算是保证该函数的幂等性。 个人疑问： 1.怎么做到这样分步展示重构过程的？我现在写，基本一边写就一边重构，停手也就差不多到合适的质量了。刻意要展示重构手法，展示的知识点会有很多疏漏，并无法做到这样一步一步的展示（下意识一步到位，并不知道怎么退到不好的代码结构）。 2.能理解栏主尽量不依赖任何框架的初衷。但对于java，spring其实才是标准，感觉是不是基于spring框架来写demo还好点？ 我现在比较喜欢让代码依赖spring框架来实现，感觉这样会显得优雅一些。栏主怎么看？

老师39,40课完整源代码可以提供下吗，我准备好好研究学习下

终于进去到期待已久的设计模式了

课堂讨论，使用一个标记flag作为该函数被调用国的标记，并给这个函数加锁，解决并发问题