本部门需要提供接口给其他多个部门使用，其他部门的代码都在不同的仓库并且没有公共的父POM项目。需要考虑其他部门的适配效率。

变更需求：增加接口调用次数等统计信息

方案

分析

通常方案有两种：

1. 本部门提供接口，其他部门通过Restful调用
2. 本部门提供JDK，其他部门调用JDK方法

分析：

方案1: 调用的接口需要各部门适配，并且后续增加其他接口以后，其他部门也需要增加调用其他接口的接口方法，比较繁琐。

方案2: 将调用的接口通过JDK的形式封装，对外提供方法，各部门构造好参数以后调用方法即可，不需要关注具体的接口内容。JDK内部封装好数据的分块切片等操作方法，下游不需要处理具体逻辑；同时数据分块切片放在各客户端处理，不需要本服务处理，缓解压力。

最后方案2通过评审。

设计

1. 请求打过来以后首先鉴权，判断是否是集团内部服务的请求【通过密钥的方式判断】
2. 如果不是抛出异常，全局捕获返回；如果是，调用对应请求接口

核心实现

密钥

生成：为每一个部门分配一个唯一的Access Key（标识）和 Secret Key（加密密钥）

存储：将两个密钥存入到数据库中。

使用：SDK封装签名的生成逻辑，其他部门只需要构造时传入Access Key（标识）和 Secret Key（加密密钥）即可。

信息统计

需要将统计信息存储到数据库，所以只能我们服务统计。

方案1(pass)：网关层处理，网关在基架部，关于业务侧统计不好处理。

方案2：AOP + Redis + 定时任务持久化。

补充

设计补充

公司部门内部通过后端调用，暂时使用前端调用。

如果后续增加前端调用，需要考虑防重放和跨域问题

防重放

方案：增加时间戳和Nonce随机数

跨域问题

方案：网关层统一配置CORS

中线：20、30、70天均线

年线：250天均线

捏住：中线如果没有跌破30天线，证明走势很强，就拿着

抛掉：缓慢推升，一旦加速上涨，就要时刻注意出货；第一波就火爆上涨，调整后的第二波上涨一旦出现背驰或者巨放量，就要准备走人

以往的跌破线：看月线图，60-70天均线，在哪跌破，哪个线就是重要的长线关口；找箱体

找牛股：如果跟盘技术不行，有一种方式是最简单的，就是盯着所有放量突破上市首日最高价（牛2024/10/8）的新股以及放量突破年线然后缩量回调年线的老股，这都是以后的黑马。特别那些年线走平后向上出现拐点的股票，一定要看好了。至于还在年线下面的股票，先别看了，等他们上年线再说。其实，这就是在牛市中最简单可靠的找所谓牛股的方法。

是否复权：看K线不复权，看历史阻力、支持位可复权。如果用5、10线，除权日线图以下的操作影响不大，不用复权。如果是周线、月线，可以复权。

消息：不要预测任何消息的影响，而是要仔细观察市场对消息的所有消息的综合反应，也就是市场的走势本身。就像感冒之于人的体质，消息是来测试市场体质的，而不是用来预测的。

飞吻：短期均线略略走平后继续按原来趋势进行下去。
唇吻：短期均线靠近长期均线但不跌破或升破，然后按原来趋势继续下去。
湿吻：短期均线跌破或升破长期均线甚至出现反复缠绕，如胶似漆。

均线系统（建议用MA5和MA10，作为短线和长线）：最简单又最实用的技术指标系统就是所谓的均线系统。任何技术指标、系统，本质上都是一个评价系统，也就是告诉你在这个系统的标准下，评价对象的强弱。利用均线构成的买卖系统，首先要利用男上位最后一次缠绕后背弛构成的空头陷阱抄底进入，这是第一个值得买入的位置，而第二个值得买入或加码的位置，就是女上位后第一次缠绕形成的低位。站在该系统下，这两个买点的风险是最小的，准确地说，收益和风险之比是最大的，也是唯一值得买入的两个点

MACD：MACD关键是处理好红绿柱子的一波，与一波中的高点转折的关系。每个红绿柱的一波都像一个小山，山顶就是转折的地方，这一看图就明白了。
但光会看红绿柱还只是初步。关键要会看上面的两条黄白线。黄白线在0轴（也就是分割红绿柱那条直线）之上就是多头行情，之下就是空头行情。
告诉大家一个缠中说缠的MACD定律：第一类买点都是在0轴之下背驰形成的，第二类买点都是第一次上0轴后回抽确认形成的。卖点的情况就反过来。

走势中枢：某级别走势类型中，被至少三个连续次级别走势类型所重叠的部分，称为缠中说禅走势中枢。换言之，缠中说禅走势中枢就是至少三个连续次级别走势类型重叠部分所构成。

盘整：在任何级别的任何走势中，某完成的走势类型只包含一个缠中说禅走势中枢，就称为该级别的缠中说禅盘整

趋势：在任何级别的任何走势中，某完成的走势类型至少包含两个以上依次同向的缠中说禅走势中枢，就称为该级别的缠中说禅趋势。该方向向上就称为上涨，向下就称为下跌

走势：你打开走势图看到的就是走势。走势分不同级别。

走势类型：上涨、下跌、盘整。

趋势：上涨、下跌。

缠中说禅走势中枢：某级别走势类型中，被至少三个连续次级别走势类型所重叠的部分。

缠中说禅盘整：在任何级别的任何走势中，某完成的走势类型只包含一个缠中说禅走势中枢，就称为该级别的缠中说禅盘整。

缠中说禅趋势：在任何级别的任何走势中，某完成的走势类型至少包含两个以上依次同向的缠中说禅走势中枢，就称为该级别的缠中说禅趋势。该方向向上就称为上涨，向下就称为下跌。

“缠中说禅技术分析基本原理一”：任何级别的任何走势类型终要完成。

“缠中说禅技术分析基本原理二”：任何级别任何完成的走势类型，必然包含一个以上的缠中说禅走势中枢。

“缠中说禅走势分解定理一”：任何级别的任何走势，都可以分解成同级别“盘整”、“下跌”与“上涨”三种走势类型的连接。

“缠中说禅走势分解定理二“：任何级别的任何走势类型，都至少由三段以上次级别走势类型构成。

全球第一博客 — 缠中说禅

教你炒股票18

实战

2024/11/18

叫你炒股票11：

东方盛虹

MA5和MA250出现纠缠，再观望观望,等中长类均线来一个缠绕。后续看涨。

上海电气

不能入手，目前男上，等女上时在考虑入手。

拥有你自己的原则

独立思考并确定：

1. 你想要什么
2. 事实是什么
3. 面对事实，你如何实现自己的愿望

我的历程

1967-1979

作者感想

• 学习冥想对我很有帮助
• 你最好弄明白其他时间、其他地点、其他人身上发生的事，因为如果你不这么做，你就不知道这些事会不会发生在你身上，而且一旦发生在你身上，你将不知道如何应对
• 当所有人想法都一样时，就不要把赌注押在这上面

---

• 把复杂的系统设想为机器，发现其内部的因果关系，把处理这些因果关系的原则写下来，将其输入计算机，从而让计算机为我“决策”
• 没有任何东西是确定的，总是会存在给你造成重大损失的风险，因此，你最好总是假设自己没有看到全部

---

• 有意义的工作：一项能全身心投入的使命；有意义的人际关系：既深深地关心对方，对方也深深地关心我
• 先确定你真正想要什么，你真正的目标是什么，你为了得到这些目标需要做什么。【把金钱、赚钱当做目标是没有意义的。赚钱只是你实现目标的附带结果】

笔者感想

• 先做事、再立名、后破圈、交人脉
• 作者是工作以后继续大学研究的方向，但是我不一样，大学研究方向和工作完全不一样

1979-1982

• 思维定式：“我是对的”—>“我怎么知道我是对的”
• 途径
  • 找到与我观点不同的最聪明的人，以便自己能够努力理解他们的推理
  • 知道自己在什么时候不能有明确的意见，不急于下结论
  • 逐步归纳永恒和普适的原则，对其进行测试，将其系统化
  • 通过平衡风险来保持较大的回报，并降低下行波动
• 只有当你能承认甚至接受自身的弱点时，你才能做出对自身有益的改变
• 想要追求卓越，你就必须挑战自己的极限，而挑战自己的极限可能会使你一蹶不振，这将造成很大的痛苦。你会觉得自己已经失败了，但这不一定是失败，除非你自己放弃。，但之后你的痛苦将会逐渐消散，你在未来将会迎来很多其他机会，尽管当时的你也许看不清这些机会。你能做的最重要的事情是总结这些失败提供的教训，学会谦逊和极度开明的心态，从而增加你成功的概率，然后继续挑战自己的极限
• 想要改进你的决策，你能做的最有价值的事情之一，是深入思考你的决策原则，同时以文字和计算机算法的形式把这些原则写下来，在条件允许的情况下进行返回测试，并以实时的方式，在用你的头脑进行决策的同时运用这些原则。

1983-1994

• 只对你有高度信心的投资对象进行冒险押注，并对这些对象进行充分的分散投资。
• 如果你以勤奋和有创造性的方式工作，你几乎可以得到你想要的任何东西，但你不可能同时得到所有东西。成熟意味着你可以放弃一些好的选择，从而追求更好的选择。
• 在没有真正通过别人的视角看待事物之前就对别人下判断，会妨碍对他们所处环境的理解，而且这样做很不明智。我建议你保持足够的好奇心，始终愿意去理解那些看问题与你不一样的人是怎么形成他们看问题的方式的。你将会发现这很有趣，而且益处无穷，而你获得的更丰富的视角将帮助你决定你应当怎么做。
• 错误日志（现在我们称其为问题日志）是我们的第一项管理工具。后来我明白了，管理工具在促使人们采用正确的行为方式方面发挥着重要作用，这一认识引导我创造了不少其他工具

---

• 1.把我们的真实想法摆在桌面上； 2.存在经过深思熟虑的分歧，但人们愿意在相互了解的过程中更改观点； 3.如果分歧依然存在，拥有一种大家一致同意的决策方式（如投票或者拥有清晰的权威），以便我们能够不带怨气地把分歧留在身后

1995-2010 P79

• 如果管理者不知道员工不同的思维方式，他就不知道员工将如何处理不同的情况
• 大多数来到桥水的人是冒险型的，也知道自己来到了一家什么样的企业。他们知道自己表现不称职的可能性高于正常情况，但依然坦然接受这一风险，因为相对于被淘汰的消极面而言，成功的积极面是巨大的。最坏的情况不过是他们对自身有了更多了解，拥有了一段有意思的经历，然后可以去尝试其他工作；最好的情况则是他们加入了一个卓越团队，取得卓越成就

2011-2015 P100

• 他们都是独立的思考者，不会让任何东西或任何人妨碍自己追求大胆的目标。对于事情应该怎么做，他们在头脑 里有十分坚定的规划，同时又始终愿意在现实中检验这些头脑规划、调整做法，从而使规划效果变得更好。他们都极为坚韧，因为相对于他们在追求梦想的过程中经历的痛苦而言，他们实现梦想的决心更强烈。
• 每当面对是实现自己的目标还是取悦他人（或不让他人失望）时，他们都会选择实现自己的目标。
• 有能力的人居安思危。安然无忧的是愚人。假如冲突能在变得尖锐之前被解决的话，世界上就不会有英雄了。

---

• 考察影响你的那些事物的规律，从而理解其背后的因果关系，并学习有效应对这些事物的原则。

  通过这样做，你将开始理解每个“再现的情境”背后的机理，并逐渐形成一个应对该情境的“意境地图”。随着你对这些关系的理解不断加深，你就能看到隐藏在扑面而来的复杂事物中的实质。你将明白你面对的事物属于哪种类型，并自然而然地运用正确的原则帮助自己渡过难关。接着，现实会向你发出强烈的信号，或者回报你或者惩罚你，以体现你的原则的运用效果，这样你就能学着相应地调整这些原则。

生活原则

1. 拥抱现实，应对现实

P134

• 世界上最重要的事情是理解现实如何运行，以及如何应对现实。努力争取伟大的目标很容易让我失败，因而我必须不断学习并想出新的主意才能继续前进。
• 卷入快速学习的反馈循环之中是件令人兴奋的事情

1.1 做一个超级现实的人

• 理解现实，接受现实，处理现实问题，既是务实的，也是美妙的。
• 创造伟大事物的人不是空想者，而是彻底地扎根于现实。做一个超级现实的人将帮助你明智地选择自己的梦想并实现它。

1. 梦想+现实+决心=成功的生活。 取得成功、推动进步的人对现实背后的因果关系有着深刻的理解，并利用原则实现自己的愿望。反过来也成立：没有深深扎根于现实的理想主义者会制造问题，而不是推动进步。

1.2 真相（对现实的准确理解）是任何良好结果的根本依据

1.3 做到头脑极度开放、极度透明

1. 对于快速学习和有效改变而言，头脑极度开放、极度透明是价值无限的
2. 不要担心其他人的看法，使之成为你的障碍
3. 拥抱极度求真和极度透明将带来更有意义的工作和更有意义的人际关系。

1.4 观察自然，学习现实规律

1. 不要固守你对事物“应该”是什么样的看法，这将使你无法了解真实的情况。

自然会走向整体的最优化，而不是个体的最优化，但多数人只是根据事物对自身的影响判断好坏。我看到的情况是正在运行的自然进程，它能有效促进整个世界的改善，比人类发明的任何程序都有效得多。

1. 一个东西要“好”，就必须符合现实的规律，并促进整体的进化，这能带来最大的回报。
2. 进化是宇宙中最强大的力量，是唯一永恒的东西，是一切的驱动力。
3. 不进化就死亡。

1.5 进化是生命最大的成就和最大的回报

1. 个体的激励机制必须符合群体的目标。

2. 现实为了整体趋向最优化，而不是为了个体。

3. 通过快速试错以适应现实是无价的。

   我们进行的学习也是这个道理。至少有三种学习能促进进化：

   • 以记忆为基础的学习（有意识地储存不断出现的信息，以便以后可以记起来）；
   • 潜意识的学习（从未进入意识的、我们从经验中习得的知识，但也会影响我们的决策）；
   • 与人类思考无关的“学习”，例如记录物种适应进程的基因的进化。

4. 意识到你既是一切又什么都不是，并决定你想成为什么样子

5. 你的未来取决于你的视角。

1.6 理解自然提供的现实教训

1. 把你的进化最大化。

2. 记住“没有痛苦就没有收获”。

   痛苦让我们清醒，帮助我们进步。

3. 自然的一项根本法则是，为了赢得力量，人必须努力突破极限，而这是痛苦的。

1.7 痛苦+反思=进步

• 如果你能养成一种习惯，面对精神痛苦时能够自动地反思痛苦而不是躲避痛苦，你将能够快速地学习和进化。直面你的问题、错误和弱点导致的痛苦现实，会大幅提高你的效率。
• 生活中的大多数东西都不过是“同类情况的重演”。你的层次越高，你就越能有效地应对现实，塑造符合你目标的结果。而曾经看起来复杂得不可思议的东西，也会变得简单。

1. 迎接而非躲避痛苦。

   从痛苦中学习，将让人“步入新境界”。

   • 找到、接受，并学会如何应对你的弱点；
   • 更喜欢周围的人对你坦诚，而不是隐瞒对你的负面看法;
   • 展现真实的自我，而不是强行把弱点伪装成优势。

2. 接受严厉的爱。

无论你想实现什么样的生活愿望，你的适应能力、在个人进化之路上快速有效前进的能力，将决定你能否成功和幸福。如果你做得好，你就能改变自己的心理反应模式，使痛苦成为某种你渴望的东西。

1.8 考虑后续与再后续的结果

直接结果经常是诱惑，导致我们失去真正想要的东西，直接结果有时也是障碍。这就好像自然正在对我们进行分类：自然扔给我们各种暗藏玄机、结果有好有坏的选择，而那些决策时只考虑直接结果的人会受到惩罚。 而有的人选择自己真正想要的东西，顶住诱惑，克服可能妨碍自己实现目标的痛苦，这样的人拥有成功人生的可能性要大得多。

1.9 接受结果

不管在生活中遇到什么情况，如果你能负起责任，进行良好的决策，而不是抱怨你无法控制的东西，你将更有可能成功并找到幸福。

1.10 从更高的层次俯视机器

1. 把自己想象成一部在大机器里运转的小机器，并明白你有能力改变你的机器以实现更好的结果。

2. 通过比较你实现的结果和你的目标，你就能确定如何改进你的机器。

3. 区别作为机器设计者的你和作为机器中工作者的你。

4. 大多数人犯下的最大错误是不客观看待自己以及其他人，这导致他们一次次地栽在自己或其他人的弱点上。

5. 成功的人能超越自身，客观看待事物，并管理事物以塑造改变。

   面对自身缺点，你有4种选择：

   • 你可以否认缺点（这是大多数人的做法）。
   • 你可以承认缺点并应对缺点，努力把缺点转化为优势（能不能成功取决于你的自我改变能力）。
   • 你可以承认缺点并找到绕过缺点的方法。
   • 或者，你可以改变你的目标。

6. 你不擅长的领域请教擅长的其他人，这是一个你无论如何都应该培养的出色技能，这将帮助你建立起安全护栏，避免自己做错事。

7. 因为客观看待自身很困难，所以你需要依赖其他人的意见，以及全部证据。

8. 如果你的头脑足够开放，足够有决心，你几乎可以实现任何愿望。

   所以可以肯定的是，我不会劝阻你追求自己设定的目标。同时，我建议你思考你追求的目标是否符合你的特性。不管你的特性是什么，总是有很多条道路适合你，所以不要固守一条道路。如果一条特定的道路走不通，你只需要找到另一条适合自己特性的好道路。

   ---

   但大多数人缺乏勇气克服自身弱点，也缺乏勇气做出这一改变所要求的不容易做出的抉择。

   归根到底，这可以总结为以下5项抉择：

   • 不要混淆你的愿望和事实。
   • 不要为自身形象担心，只需关心能不能实现你的目标。
   • 不要过于重视直接结果而忽视后续、再后续的结果。
   • 不要让痛苦妨碍进步。
   • 不要把不好的结果归咎于任何人，从自己身上找原因。

2. 用五步流程实现你的人生愿望

1. 有明确的目标。
2. 找到阻碍你实现这些目标的问题，并且不容忍问题。
3. 准确诊断问题，找到问题的根源。
4. 规划可以解决问题的方案。
5. 做一切必要的事来践行这些方案，实现成果。

2.1 有明确的目标

1. 排列优先顺序：尽管你几乎可以得到你想要的任何东西，但你不可能得到你想要的所有东西。 （工作or游戏）

2. 不要混淆目标和欲望。

   合理的目标是你真正需要实现的东西，欲望则是你想要但会阻止你实现目标的东西。

3. 调和你的目标和欲望，以明确你在生活中真正想要的东西。

   是让激情消耗你，驱使你做出不理性的行为，还是你驾驭激情，从而得到动力来追求你真正的目标？

4. 不要把成功的装饰误认为成功本身。

5. 永远不要因为你觉得某个目标无法实现就否决它。

6. 谨记伟大的期望创造伟大的能力。

7. 如果你拥有灵活性并自我归责，那么几乎没有什么能阻止你成功。

   灵活性能让你接受现实（或者有见识的人）给你的教益。

8. 知道如何对待挫折和知道如何前进一样重要。

   在逆境中，你的目标应该是守住自己的成绩，尽量减少损失，或者直面不可挽回的损失。

2.2 找出问题，并且不容忍问题

1. 把令人痛苦的问题视为考验你的潜在进步机会。

2. 不要逃避问题，因为问题根植于看起来并不美好的残酷现实。

   承认你的弱点并不是向弱点投降，而是克服弱点的第一步。你感到的痛苦是“成长的痛苦”，它将考验你的个性，当你忍痛前行时给你回报。

3. 要精准地找到问题所在。

   你应该找准问题，因为不同的问题有 不同的解决方案。

4. 不要把问题的某个原因误认为问题本身。

5. 区分大问题和小问题。

   你的时间和精力有限，确保你正将其用于探寻大问题，即一旦解决便能带来最大回报的问题。但同时，留出足够多的时间来探寻小问题，以确保这些小问题不是更大问题的征兆。

6. 找出一个问题之后，不要容忍问题。

   你必须养成一种对任何性质的恶习都绝不容忍的习惯，无论其是重是轻。

2.3 诊断问题，找到问题的根源

1. 先把问题是什么弄明白，再决定怎么做。

2. 区分直接原因和根本原因。

   直接原因通常是导致问题的行动（或不行动），所以通常用动词描述（我因为没有查列车时刻表而错过了火车）。根本原因是更深层的原因，通常用形容词描述（我因为健忘而没有查列车时刻表）。只有消除根本原因才能真正解决问题，为此你必须区分症状和疾病本身。

3. 认识到了解人（包括你自己）的特性，有助于对其形成合理预期。

2.4 规划方案

1. 前进之前先回顾。

   回顾一下在你到达现在所处的位置之前，你经历过什么（或做过什么），然后设想为了实现你的目标，你和其他人未来应该怎么做。

2. 把你的问题看作一部机器产生的一系列结果。

3. 谨记实现你的目标通常有很多途径。

4. 把你的方案设想为一个电影剧本，然后循序渐进地思考由谁来做什么事。

5. 把你的方案写下来，让所有人都能看到，并对照方案执行。

6. 要明白，规划一个好方案不一定需要很多时间。

   谨记：规划先于行动！

2.5 坚定地从头至尾执行方案

1. 规划做得再好，不执行也无济于事。

   你应当时刻谨记任务及其意在实现的目标之间的联系。当你觉得看不清其间的联系时，就暂停一下，问问自己为什么看不清。找不到原因，你就肯定会迷失自己的目标。

2. 良好工作习惯的重要性常被大大低估。

3. 建立清晰的衡量标准来确保你在严格执行方案。

2.6 谨记：如果你找到了解决方案，弱点是不重要的

1. 考察你犯错误的类型，并识别你通常在五步流程中的哪一步上做得不好。
2. 每个人都至少有一个最大的弱点阻碍其成功，找到你的这个弱点并处理它。

成功有两条路：（1）自己拥有成功所需的要素；（2）从其他人那里得到成功所需的要素。第二条路需要你谦逊。谦逊和你自己有能力一样重要，甚至比你有能力更重要。谦逊和能力兼有是最好的。

2.7 理解你和其他人的“意境地图”(认知能力)与谦逊性

3. 做到头脑极度开放

3.1 认识你的两大障碍

影响合理决策的两个最大的障碍是你的自我意识和思维盲点。

1. 理解你的自我意识障碍。

   “自我意识障碍”是指你潜意识里的防卫机制，它使你难以接受自己的错误和弱点。

2. “两个你”在争夺对你的控制权。

3. 理解你的思维盲点障碍。

   适应和进化有三种途径：

   （1）训练自己的头脑以反直觉的方式思考（例如有创造力的人通过自律和练习变得更有条理）

   （2）利用辅助机制（例如程序化的提醒器）

   （3）在自己的短板上，依靠擅长者的帮助

3.2 奉行头脑极度开放

1. 诚恳地相信你也许并不知道最好的解决办法是什么，并认识到，与你知道的东西相比，能不能妥善处理“不知道”才是更重要的。

2. 认识到决策应当分成两步：先分析所有相关信息，然后决定。

   听听其他人的观点并加以考虑，绝不会削弱你独立思考、自主决策的自由，只会让你在决策时有更宽广的视角。

3. 不要担心自己的形象，只关心如何实现目标。

4. 认识到你不能“只产出不吸纳”。

5. 认识到为了能够从他人的角度看待事物，你必须暂时悬置判断，只有设身处地，你才能合理评估另一种观点的价值。

6. 谨记，你是在寻找最好的答案，而不是你自己能得出的最好答案。

7. 搞清楚你是在争论还是在试图理解一个问题，并根据你和对方的可信度，想想哪种做法最合理。

   “可信”的人有两个特征：曾反复地在相关领域成功找到答案（至少成功过三次，拥有过硬履历）；在被问责的情况下能对自己的观点做出很好的解释。

3.3 领会并感激：深思熟虑的意见分歧

在深思熟虑的意见分歧中，你的目标不是让对方相信你是对的，而是弄明白谁是对的，并决定该怎么做。

人们在发生分歧时变得愤怒是毫无意义的，因为大多数分歧与其说是威胁，不如说是学习的机会。

如果你们发现讨论陷入了僵局，就商定一个你们都尊重的人，让他帮着主持讨论。

3.4 和可信的、愿意表达分歧的人一起审视你的观点

1. 为最坏的情况做准备，以尽量使其不那么糟糕。

以开放心态与可信的人一起审视问题，你将大幅提升做出正确决策的概率。

3.5 识别你应当注意的头脑封闭和头脑开放的不同迹象

3.6 理解你如何做到头脑极度开放

练习头脑开放，可以：

1. 经常利用痛苦来引导自己进行高质量的思考

2. 将头脑开放作为一种习惯。

   如果你始终把愤怒感、挫败感作为提醒自己的迹象，从而冷静，慢下来，以深思熟虑的方式看待眼前的问题，逐渐地，你的负面情绪出现的频率就会大大下降

3. 认识自己的思维盲点。

4. 假如很多可信的人都说你正在做错事，只有你不这么看，你就要想想自己是不是看偏了。

5. 冥想。“超验冥想”

6. 重视证据，并鼓励其他人也这么做。

   在准备决策时问问自己：你能说出是哪些明确的事实（即可信的人不会质疑的事实）让你形成这种观点吗？如果你不能，你就很有可能不是在依据证据行动。

7. 尽力帮助其他人也保持头脑开放。

8. 使用以证据为基础的决策工具。

9. 知道什么时候应当停止为自己的观点辩护，信任自己的决策程序。

在我看来，人一生最重要的抉择只有一个：你愿意努力探寻真相吗？

4. 理解人与人大不相同

独立的思考者，有创造力，概念性强，常识性强

4.1 明白你与其他人的思维方式能带来的力量

1. 我们拥有各种天生特征，既可能帮助自己也可能伤害自己，取决于如何应用。

理解大脑这部“思维机器”的运行方式，始终是极为美妙和有益的。

人脑的复杂程度超出我们的想象。

新生儿的大脑里就包含了数亿年生物进化累积的成果。

所有哺乳动物、鱼类、鸟类、两栖动物、爬行动物的脑都拥有同一套伟大的构造

这一“所有脊椎动物共有的脑”的进化是自下而上进行的，也就是说，较低的区域是进化意义上最古老的，顶层区域是最新的。

4.2 有意义的工作和有意义的人际关系不仅是我们做出的美好选择，而且是我们天生的生理需求

4.3 理解大脑里的主要斗争，以及如何控制这些斗争，以实现“你”的愿望

1. 明白，意识与潜意识在不断斗争。

   我们的灵感大爆发往往就是从潜意识区域“喷出”的。当你说“我刚刚想到了什么事”时，你就是注意到了你的潜意识正在告诉意识一些东西。加以训练，开启这个通信流是可能的。

   当我的潜意识给我想法和提示 时，我不是马上按照其行动，而是先用我的理性意识去分析它们。

2. 要知道最常发生的斗争是情绪和思考的斗争。

   情绪主要是由潜意识性的杏仁核控制的，而理性思考主要是由意识性的前额皮层控制的。

3. 调和你的情绪和思考。

   对大多数人而言，生活就是大脑这两个部分永无止境的斗争。杏仁核产生的反应是一阵爆发然后平息，而前额皮层产生的反应更为稳定和持久。

4. 善择你的习惯。

   习惯是由大脑底部的基底核驱动的，那是一块高尔夫球大小的组织。基底核控制着你的行为，但它藏得很深，本能地运行，所以你意识不到它。

   只要频繁反复练习，你几乎可以养成任何习惯，产生自控力。好习惯让你实现“较高层次的自我”的愿望，而坏习惯是由“较低层次的自我”控制的，阻碍前者的实现。

   分三步走的“习惯回路”。第一步是信号，“用信号来告诉你的大脑进入自动运行模式，以及使用哪种习惯”。第二步是形成常规，“可以是肢体性、心理性或情感性的常规”。第三步是奖励，这能帮助你的大脑发现这个特定的回路是不是“值得记下来以备后用”。

5. 坚持友善地训练“较低层次的你”，以养成好的习惯。

6. 理解右脑思维和左脑思维的差别。

1. 理解大脑可以改变的程度。

   大脑可塑性是指大脑的“软线路”可以在多大程度上改变。

4.4 认识自己和他人的特性

1. 内向与外向。内向者聚焦于内心世界，从思想、记忆和经验中 汲取能量；外向者聚焦于外部，从与人相处中汲取能量。
2. 直觉与感知。
3. 思考与感觉。
4. 计划与发觉。
5. 创造者、推进者、改进者、贯彻者与变通者。
6. 关注任务与关注目标。
7. 职场人格量表。
8. 塑造者是能从构想一路走到构想实现的人。

4.5 无论你要实现什么目标，让合适的人各司其职以支持你的目标，是成功的关键

1. 管理你自己，并协调其他人实现你的目标。

5. 学习如何有效决策

5.1 要认识到：（1）影响好决策的最大威胁是有害的情绪；（2）决策是一个两步流程（先了解后决定）

了解必须先于决定。

把了解做好

5.2 综合分析眼前的形势

你必须能分清哪些“点”重要，哪些不重要。

1. 你能做的最重要的决定之一是决定问谁。
2. 不要听到什么信什么。
3. 所有东西都是放在眼前看更大。
4. 不要夸大新东西的好处。
5. 不要过度分析细节。

5.3 综合分析变化中的形势

1. 始终记住改善事物的速度和水平，以及两者的关系。

2. 不必过于精确。

3. 谨记“80/20法则”，并明白关键性的“20%”是什么。

4. 不要做完美主义者。

   完美主义者花太多时间关注边缘性的微小因素，影响对重大因素的考虑。做出一个决定时通常只有5—10个需要考虑的重要因素。重要的是深入了解这些因素，而过了一定的临界点后，即使研究重要因素，所产生的边际收益也是有限的。

5.4 高效地综合考虑各个层次

1. 用“基线以上”和“基线以下”来确定谈话位于哪一层。
2. 谨记，决策需要在合理的层次做出，但也应在各层次之间保持一致。

5.5 综合分析现实、理解如何行动的最好工具是逻辑、理性和常识

除非你意识到你的潜意识，否则潜意识将主导你的人生，而你将其称为命运。

5.6 根据预期价值计算做决策

1. 不管你押对的概率已经有多大，提高你的押对概率始终有价值。
2. 知道什么时候不要去押注，和知道什么注值得押同样重要。
3. 最好的选择是好处多于坏处的选择，不是毫无坏处的选择。

5.7 比较更多信息带来的价值和不做决定造成的成本，决定优先顺序

1. 先把你的“必做之事”做完，再做你的“想做之事”。

2. 你很可能没有时间处理不重要的事，那最好将它留着，以免自己没有时间处理重要的事。

3. 不要把概率当作可能性。

   万事皆有可能，重要的是概率。你必须考虑每个因素的发生概率，然后进行排序。

5.8 简化

5.9 使用原则

• 让你的思维慢下来，以注意到你正在引用的决策标准。
• 把这个标准作为一项原则写下来。
• 当结果出现时，评估结果，思考标准，并在下一个“类似情境”出现之前改进标准。

5.10 对你的决策进行可信度加权

5.11 把你的原则转换成算法，让计算机和你一起决策

5.12 在深刻理解人工智能之前不要过度信赖它

为了拥有最好的生活，你必须：

（1）知道最好的决策是什么；

（2）有勇气做出最好的决策。

工作原则

一个机构就像一部机器，主要由两组部件构成：文化和人

• 优秀的机构拥有优秀的人和优秀的文化。

• 优秀的人具备高尚的品格和出色的能力。

• 优秀的文化不掩盖问题和分歧，而是公开妥善解决，喜欢让想象力驰骋且愿意开创先河。

严厉之爱有助于成就优异的工作业绩和建立良好的人际关系

为了成就伟大事业，对不应妥协的事情就必须坚持立场、寸步不让。

基于可信度加权的创意择优是实现有效决策的最佳模式

让热情与工作合二为一，并与志同道合者倾力推进(P304)

工作，

要么是（1）你想从事用于养家糊口的一份职业，

要么是（2）你想完成的使命，

要么是二者的结合体。

缺口

RSI（短线参考）

MACD（中长期参考）

KDJ（随机震荡；短期参考；参考难度大）

• 以50为分界线

筹码（缺点多，参考）

• 第二天实体包住第一天全部

• 第一天实体包住第二天全部

进度管理

进度管理包括哪些过程

1
2
3
4
5
6

1. 活动定义：确定完成项目的各个可交付成果所必须进行的各项具体活动
2. 活动排序
3. 活动资源估计
4. 活动历时估算
5. 制定进度计划
6. 进度控制

盈亏分析

正常情况、盈亏平衡时的公式

1
2

正常情况：销售额 = 固定成本 + 可变成本 + 税费 + 利润
盈亏平衡：销售额 = 固定成本 + 可变成本 + 税费 + 0

软件配置管理

产品配置有哪些配置项

1
2
3
4

基线配置项（可交付成果）：需求文档、设计文档、源代码、测试用例、运行所需数据等
非基线配置项：各类计划、各类报告

产品配置就是一个产品在其生命周期各个阶段所产生的各种形式和各种版本的集合。

软件配置管理(SCM)的核心内容

1

版本控制和变更控制

软件质量管理

软件质量保证的主要内容

1
2
3
4

软件质量保证（SQA）：
1. SQA审计和评审
2. SQA报告
3. 处理不符合问题

软件能力成熟度模型集成CMMI等级

1
2
3
4
5
6

成熟度由低到高
1. 初始级：随意且混乱、组织成功依赖于个人能力
2. 已管理级：项目级可重复【建立了项目级的控制过程】
3. 已定义级：组织级，文档化、标准化
4. 定量管理级：量化式管理【过程性能可预测】
5. 优化级：持续优化

开发模型

软件工程有哪些开发模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

1. 瀑布模型【*】
- 严格区分阶段，每个阶段因果关系紧密相连
- 只适合需求明确的项目
2. 原型模型【*】
- 原型模型两个阶段：原型开发阶段和目标软件开发阶段
- 适合需求不明确的项目
- 分为抛弃型原型（快速原型）和演化性原型
3. V模型
- 测试贯穿于始终
- 需求分析对应验收测试与系统测试；概要设计对应集成测试，详细设计对应单元测试。
4. 迭代与增量
5. 螺旋模型【*】
- 以快速原型为基础 + 瀑布模型
- 考虑了风险问题
6. 基于构件的开发模型（CBSD）
- 易拓展、易重用、降低成本、安排任务更灵活
- 要求架构师能力高
7. 基于构件的软件工程（CBSE）
- 体现了购买而不是重新构造的哲学
8. 快速应用开发（RAD）
- SDLC(瀑布) + CBSD(基于构件)
9. 软件统一过程（UP/RUP）【*】
10. 敏捷模型【*】

软件工程有哪些过程模型（新版）

1
2
3
4

1. 瀑布模型
2. 原型模型
3. 软件统一过程（UP/RUP）
4. 敏捷模型

CBSE构件所应该具备的特征

1
2
3
4
5

1. 可组装性：所有外部交互必须通过公开定义的接口进行
2. 可部署性：构件总是二进制形式的，能作为一个独立的实体在平台上运行
3. 文档化：用户根据文档来判断构件是否满足需求
4. 独立性：可以在无其他特殊构件的情况下进行组装和部署
5. 标准化：符合某种标准化的构件模型

CBSE构件的组装顺序

1
2
3

1. 顺序组装：按顺序调用已存在的构件，可以用两个已经存在的构件来创造一个新的构件
2. 层次组装：被调用构件“提供”的接口必须和调用构件的“请求”接口兼容
3. 叠加组装：多个构件合并形成新的构件，新构件整合原构件的功能，对外提供新的接口

RUP模型的几个阶段

1

初始->细化->构造->移交

RUP的4+1视图模型

1
2

逻辑、实现、用例、进程、部署
P50

净室软件工程（CSE）的技术手段

1
2
3
4

1. 统计过程控制下的增量式开发：控制迭代
2. 基于函数的规范和设计：盒子结构
3. 正确性验证：净室软件工程的核心
4. 统计测试和软件认证：使用统计学原理，总体太大时采用抽样

净室软件工程（CSE）的缺点

1
2
3

1. 太过理论化，正确性验证的步骤困难且耗时
2. 不进行传统的模块测试
3. 带有传统软件工程的弊端

需求工程

需求工程有几个阶段

1
2
3
4
5
6
7

1. 需求获取
2. 需求分析
3. 形成需求规格（需求文档化）【SRS】
4. 需求的确认与验证【形成需求基线】
5. 需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】

注：1-4 也叫需求开发。5需求管理是对需求基线进行管理

需求的分类

1
2
3
4
5
6
7
8

分层维度：
1. 业务需求
2. 用户需求
3. 功能需求
QFD（项目管理维度）：
1. 基本需求
2. 期望需求
3. 兴奋需求

需求获取方法

1
2
3
4
5
6

用户面谈：成本高，有领域知识
联合需求计划（JRP）：交互好，各方参与
问卷调查：用户多，成本低
现场观察：针对复杂流程
原型化方法：解决早期需求不明确
头脑风暴：新业务，发散思维

需求分析（系统分析/设计）的方法

1
2
3
4

1. 结构化方法
2. 面向对象方法
3. 其他方法（软件重用）
4. 逆向工程

结构化分析方法使用的手段

1
2
3

数据流图DFD
状态转换图
ER图

面向对象方法使用的手段

1

UML

UML的4+1视图

需求定义（需求文档化所用到的方法）

1
2
3
4
5
6
7
8
9

1. 严格定义法
- 所有需求都能被预先定义
- 开发人员和用户之间能够准确而清晰地交流
- 采用文字/图形充分体现最终系统
2. 原型法
- 开发前需求不明确
- 交流困难
- 需要实际的、可供用户参与的系统模型
- 有合适的系统开发环境

软件设计

软件设计分为哪几类

1
2
3
4

1. 软件系统建模
2. 结构化设计
3. 面向对象设计
4. 界面设计

有哪几种软件系统建模方法

结构化设计的分类和原则

1
2
3
4
5
6
7
8
9

分类：
1. 概要设计【外部设计】：功能需求分配给软件模块，确定每个模块的功能和调用关系，形成模块结构图
2. 详细设计【内部设计】：为每个具体任务选择适当的技术手段和处理方法

原则：
1. 模块独立性原则（高内聚，低耦合）
2. 保持模块大小适中
3. 多扇入，少扇出
4. 深度和宽度均不宜过高

结构化设计中模块的四个要素

1
2
3
4

1. 输入和输出
2. 处理功能
3. 内部数据
4. 程序代码

结构化设计中内聚、耦合的类型

面向对象设计的基本过程

面向对象设计中类的分类

1
2
3

1. 边界类：API接口；用户界面；显示屏；二维码；购物车；
2. 控制类：排除法
3. 实体类：学员；课程

界面设计的法则

1
2
3

1. 置于用户控制之下
2. 减少用户的记忆负担
3. 保持界面的一致性

测试

测试的分类（类型）

1
2
3
4
5
6
7
8

动态测试【计算机运行】
- 白盒
- 黑盒
- 灰盒
静态测试【人工监测和计算机辅助分析】
- 桌前检查
- 代码审查
- 代码走查

测试的方法

1
2
3
4
5
6
7
8
9
10

白盒测试【结构测试】：主要用于单元测试
- 控制流测试（语句覆盖最弱，路径测试覆盖最强）
- 数据流测试
- 程序变异测试
黑盒测试【功能测试】：主要用于集成、确认、系统测试
- 等价类划分
- 边界值分析
- 错误推测
- 判定表
- 因果图

测试有哪些阶段

1

V模型

维护

遗留系统演化策略是什么

1
2
3
4
5
6
7
8
9
10
11
12
13

高水平低价值【信息孤岛】：集成
- 遗留系统的技术含量较高，但其业务价值较低，可能只完成某个部门（或子公司）的业务管理。这种系统在各自的局部领域里工作良好，但对于整个企业来说，存在多个这样的系统，不同的系统基于不同的平台、不同的数据模型，形成了一个个信息孤岛，对这种遗留系统的演化策略为集成。

高水平高价值：改造（包括系统功能增强和数据模型改造）
- 遗留系统具有较高的业务价值，基本上能够满足企业业务运作和决策支持的需要。这种系统可能建成的时间还很短，对这种遗留系统的演化策略为改造。改造包括系统功能的增强和数据模型的改造两个方面。系统功能的增强是指在原有系统的基础上增加新的应用要求，对遗留系统本身不做改变；数据模型的改造是指将遗留系统的旧的数据模型向新的数据模型的转化。

低水平低价值：淘汰
- 遗留系统的技术含量较低，且具有较低的业务价值。对遗留系统的完全淘汰是企业资源的根本浪费，系统分析师应该善于“变废为宝”，通过对遗留系统功能的理解和借鉴，可以帮助新系统的设计，降低新系统开发的风险。

低水平高价值：继承
- 遗留系统的技术含量较低，已经满足企业运作的功能或性能要求，但具有较高的商业价值，目前企业的业务尚紧密依赖该系统。对这种遗留系统的演化策略为继承。在开发新系统时，需要完全兼容遗留系统的功能模型和数据模型。为了保证业务的连续性，新老系统必须并行运行一段时间，再逐渐切换到新系统上运行。

开发新系统时，需要完全兼容遗留系统的功能模型和数据模型

软件维护有哪些类型

1
2
3
4

1. 正确性维护【修BUG】：识别和纠正软件的错误/缺陷
2. 适应性维护【应变】：应用软件适应环境变化而进行的修改
3. 完善性维护【新需求】：扩充功能和改善性能而进行的修改
4. 预防性维护【针对未来】：为了适应未来的软硬件环境的变化

影响可维护性的因素有哪些

1
2
3
4
5

1. 可理解性
2. 可修改性
3. 可测试性
4. 可靠性
5. 可移植性

系统工程

系统工程的概念和特点

1
2

1. 系统工程利用计算机作为工具，对系统的结构、元素、信息和反馈等进行分析，以达到最优规划、最优设计、最优管理和最优控制的目的
2. 从整体出发、从系统观念出发，以求整体最优

系统工程有哪些方法

1
2
3
4
5

1. 霍尔三维结构
2. 切克兰德方法
3. 并行工程方法
4. 综合集成方法
5. WSR系统方法

霍尔三维结构是哪三维？各维度特点？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

1. 逻辑维
2. 时间维
3. 知识维

逻辑维：会定义和分析系统的要素、子系统、过程、功能以及相互之间如何协作
- 明确问题
- 确定目标（建立价值体系或评价体系）
- 系统综合
- 系统分析
- 优化（解决方案的优化选择）
- 系统决策
- 实施计划

时间维：这个维度强调过程、阶段、状态、趋势和系统的生命周期。会使用时序图、甘特图或者PERT图等工具来规划和监控项目进度。
- 规划阶段（调研，谋求活动的规划与战略）
- 拟定方案（提出具体的计划方案）
- 研制阶段（完成研制方案及生产计划）
- 生产阶段（生产零部件及提出安装计划）
- 安装阶段（安装完毕，完成系统的运行计划）
- 运行阶段（系统按照预期的用途开展服务）
- 更新阶段（改进原有系统、或消亡原有系统）

知识维：知识维关注于“我们如何了解和控制系统”，即所需的技术、原则、理论、数据和经验。

切克兰德方法的过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14

1. 认识问题
实地考察公园、与公园管理员、游客、维护人员等进行交流，收集他们对现状的看 法，如公园保洁不足、娱乐设施老化等问题。
2. 根底定义
对于每个关键问题制定根底定义，比如，“公园维护系统”可能有这样的根底定 义：“一个旨在提供清洁、安全、愉悦环境的服务系统。”
3. 建立概念模型
依据“公园维护系统”的根底定义，构建一个包括垃圾回收、设施检查、游客反馈处理等活动的概念模型。
4. 比较与探寻
把概念模型与实际的公园运营情况相比较，识别出哪些是按照概念模型运作得好的地方，哪些是存在差异的地方，并探讨为什么会有这种差异。
5. 选择
决定一系列改变，例如增加保洁人员、更新娱乐设施、创建游客反馈系统等，这些都是在现实条件下可行且期望达到的改变。
6. 设计与实施
制定具体行动计划来实施这些改变，比如招聘更多的保洁人员、购置新的设施或开发一个在线反馈平台。
7. 评估与反馈
在实施后，持续对改变效果进行监测和评估，收集游客、员工的反馈，并根据反馈结果调整行动计划。

并行工程的特点

1
2
3

1. 产品设计开发期间，最快速度按质完成
2. 各项工作期间问题协调解决
3. 适当的信息系统工具

综合集成方法的原则

1
2
3
4

1. 整体论原则
2. 相互联系原则
3. 有序性原则
4. 动态原则

WSR系统方法的三个关键维度

1
2
3

技术层面（物理）
管理层面（事理）
人文层面（人理）

系统工程生命周期阶段及方法

1
2
3
4
5
6
7

探索性研究
概念阶段
开发阶段
生产阶段
使用阶段
保障阶段
退役阶段

信息系统基础

信息系统的生命周期是什么

1
2
3
4
5
6
7
8
9

1. 产生
2. 开发
    - 总体规划
    - 系统分析
    - 系统设计
    - 系统实施
    - 系统验收
3. 运行
4. 消亡

信息系统的建设原则

1
2
3
4

1. 高层管理人员介入
2. 用户参与开发
3. 自顶向下
4. 工程化

信息系统开发方法(BOOK)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// 以书本为主，一下内容参考 //

1. 结构化方法
特点：
- 自顶向下，逐步分解求精
- 开发目标清晰化
- 工作阶段程式化
- 开发文档规范化
- 设计方法结构化
- 应变能力差
2. 面向对象方法
特点：
- 自底向上
- 阶段界线不明
- 更好的应变、更好的复用
- 符合人们的思维习惯
3. 面向服务方法
特点：
- 粗粒度、松耦合
- 标准化和构件化
- 抽象级别：操作->服务->业务流程
4. 形式化方法
- 应用数学和逻辑的严格技术，以确保软件或系统设计的正确性和一致性。
5. 统一过程方法(RUP)
特点：
- 是一个迭代和增量的软件开发框架，旨在通过结构化的阶段和多个迭代来逐步细化和完善软件产品。
- 以架构为中心，用例驱动，迭代与增量
- 四个阶段：初始、细化、构造、交付
6. 敏捷方法
- 一组灵活、迭代的软件开发实践，旨在快速响应需求变化并促进跨职能团队之间的密切协作。
7. 基于架构的开发方法(ABSD)
- 以软件系统的结构设计为核心，围绕创建、维护和演化系统架构来组织开发活动的方法。

信息系统的分类

1
2
3
4
5
6
7
8
9

1. 业务处理系统【TPS】
- 又称为电子数据处理系统
- 在服务于组织管理层次中最底层，最基础的信息系统
- 包含五个活动：数据输入、业务处理、文件和数据库处理、文件和报告产生、查询处理活动
2. 信息管理系统【MIS】
3. 决策支持系统【DSS】
4. 专家系统【ES】
5. 办公自动化系统【OA】
6. 企业资源计划【ERP】

企业信息化

企业信息化（组织信息化）的目的、需求是什么

1
2
3
4
5

目的：提高企业的竞争力
需求：
1. 战略需求：提升组织的竞争能力
2. 运作需求：实现信息化战略目标、运作策略、人才培养的需要
3. 技术需求：信息技术层面上对系统的完善、升级、集成

企业信息化有哪些方法

1
2
3
4
5
6

1. 业务流程重构方法：彻底的、根本性的重新设计流程
2. 核心业务应用方法：围绕核心业务推动信息化
3. 信息系统建设方法：建设信息系统作为企业信息化的重点和关键
4. 主题数据库方法：建立面向企业核心业务的数据库，消除信息孤岛
5. 资源管理方法：切入点是为了企业资源管理提供强大的工具
6. 人力资本投资方法：把一部分企业的优秀员工看作是一种资本

企业信息化体系全览图

企业信息化模型有哪些

1
2
3
4
5
6
7
8
9
10
11
12

1. 企业资源计划ERP
- 进化流程：物料需求管理->制造资源计划（核心是物流）->企业资源计划（重心转移到财务上）
- 主要功能模块：财会管理；物流管理；生产控制管理；人力资源管理
2. 客户关系管理CRM
- 目的：提高收入；核心思想：以客户为中心
3. 供应链管理SCM
- 强强联合，打通企业间的”信息孤岛“
- 信息化的“三流”。信息流、资金流、物流
4. 商业智能BI
5. 数据湖
6. 业务流程重组BPR和业务流程管理BPM
- 前者是颠覆原有流程、后者循环改进

商业智能BI和数据湖是什么，二者有什么区别(BOOK)

1
2
3
4
5
6
7
8
9
10
11
12

// 以书本为主，一下内容参考 //

1. 商业智能：用于决策分析，使用OLAP在线分析处理
- 应用：数据仓库和数据挖掘

2. 数据湖：存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析和传输。
- 数据分类：结构化数据（表格数据）、非结构化数据（图片、视频、音频、文档）

二者区别：
数据仓库：仅支持数据分析处理。
数据湖：即支持数据分析处理，也支持事务处理。
具体见下图：

信息系统战略规划

信息系统战略规划和企业信息化规划的区别

1
2
3

企业信息化规划：涉及多个领域的融合，它是企业战略、管理规划、业务流程重组等内容的综合规划活动。其中，企业战略规划是评价环境和企业现状，进而选择和确定企业的总体和长远目标，制定和抉择实现目标的行动方案。

信息系统战略规划：关注如何通过信息系统来支撑业务流程的运作，进而实现企业的关键业务目标。

信息系统战略规划的三个阶段

1
2
3

第一阶段：以数据处理为核心围绕职能部门需求
第二阶段：以企业内部MIS为核心围绕企业整体需求
第三阶段：综合考虑企业内外环境以集成为核心，围绕企业的战略需求

信息系统战略规划每个阶段的方法

1
2
3
4
5
6
7
8
9
10
11
12

第一阶段：
- 关键成功因素法CSF
- 战略集合转化法SST
- 企业系统规划法BSP
第二阶段：
- 战略数据规划法SDP：主题数据库
- 信息工程法IE
- 战略栅格法SG
第三阶段：
- 价值链分析VCA
- 战略一致性模型

企业应用集成EAI

什么是企业应用集成，以及作用

1
2

企业各系统互联互通，就是企业应用集成。
作用：传统企业系统未互联互通，存在信息孤岛，这种架构也被称为烟囱架构。企业应用集成就是用于消除信息孤岛。

有哪些企业集成方式

1
2
3
4
5
6
7

业界没有一个统一的标准
普遍：
1. 表示集成（界面集成）
2. 数据集成
3. 控制集成（应用集成，API集成）
4. 业务流程集成（过程集成，B2B）
5. 门户集成

各集成方式对比

门户集成的分类

信息系统新技术

有哪些信息系统的新技术

1
2

1. 数字化
2. 智能制造

notifier()：前端消息处理器，用来统一处理WebSocket消息。

notifier#attachMessageEvent：添加消息事件，参数为事件event

事件event：由各个控制器定义，不同controller内自己定义、实现。比如新建newProjectController、刷新updateController

添加方式：假设事件实现为notifierMessage，如果notifierMessage内代码有this（使用了controller中的对对象），则只能使用箭头函数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// updateController类中
// 1. 箭头函数（匿名函数）
notifier().attachMessageEvent(message => {
      this.notifierMessage(message);
});

// 2. 有引用的箭头函数（匿名函数）
this._messageFunction = message => {
    this.notifierMessage(message);
};
notifier().attachMessageEvent(this._messageFunction);

// 3. 直接传递
notifier().attachMessageEvent(this.notifierMessage);

前两种：
  this 关键字指的是箭头函数外部的 this 上下文，也就是定义 notifierMessage 方法的对象的上下文。
  箭头函数继承了其外部作用域的 this 值，因此 this.notifierMessage 将引用正确的 
  notifierMessage 方法。
【第二种有个好处是可以获取到匿名函数，因为匿名函数有了一个引用this._messageFunction， 
  通过this._messageFunction 即可获取这个匿名函数。比如需要notifier取消绑定该事件消息时，
  需要根据引用，只能使用第二种方式】

最后一种：this 关键字同样指的是定义 notifierMessage 方法的对象的上下文。
  但是，需要注意的是，在非严格模式下，当一个函数作为普通函数调用
  时（而不是作为对象的方法），this 的值通常会被设置为
  全局对象（在浏览器中是 window）。因此，如果没有明确绑定 
  this，notifierMessage 可能不会按照预期工作。
【因为是将event传递给notifier，后续由notifier调用，所以作为普通函数调用。】

区别总结

• 代码片段一：

• • 使用了一个箭头函数来包裹对 this.notifierMessage 的调用。
    • 保证了 this 的正确上下文，即使 notifierMessage 方法内部依赖于 this 的值。

• 代码片段二：

• • 直接传递 this.notifierMessage 方法给 attachMessageEvent。
    • 如果 notifierMessage 内部依赖于 this 的值，并且该方法不是作为对象的方法被调用，可能会导致 this 的值不符合预期。

注意：

notifier 添加的事件是 controller中的函数，所以当controller对象被回收时（没有controller对象引用时）这个事件也就失效了。即对象被垃圾回收以后，其他 引用该对象方法的 方法，也会失效。比如，controller 被回收以后，notifier中注册的该 controller 的 this.notifierMessage 方法也失效了。

参考视频：https://www.bilibili.com/video/BV1P44y1N7QG/?p=8&spm_id_from=pageDriver&vd_source=85ac5ee1b07df12a44b648a8751d30f6

参考文章：https://mofan212.github.io/posts/Spring-Forty-Nine-Lectures-Container-And-Bean/

Spring容器

以 SpringBoot 的启动类为例：

1
2
3
4
5
6
7

@Slf4j
@SpringBootApplication
public class A01Application {
    public static void main(String[] args) {
        SpringApplication.run(A01Application.class, args);
    }
}

其中，run()方法存在返回值，返回 ConfigurableApplicationContext 容器

1

ConfigurableApplicationContext context = SpringApplication.run(Application.class, args);

ConfigurableApplicationContext 接口继承了 ApplicationContext 接口，而 ApplicationContext 接口又间接地继承了 BeanFactory 接口，除此之外还继承了其他很多接口，相当于对 BeanFactory 进行了拓展。

BeanFactory

• 是 ApplicationContext 的父接口
• 是 Spring 的核心容器，主要的 ApplicationContext 实现 组合 了它的功能，也就是说，BeanFactory 是 ApplicationContext 中的一个成员变量。

常用的 context.getBean(“xxx”) 方法，其实是调用了 BeanFactory 的 getBean() 方法。

其他方法：

1
2
3
4

preInstantiateSingletons()：预先初始化单例对象
addEmbeddedValueResolver()：给beanFactory加入解析器
    常见参数：
    - new StandardEnvironment()::resolvePlaceholders ： ${} 解析器

基于它的子接口：

• ListableBeanFactory：提供获取 Bean 集合的能力，比如一个接口可能有多个实现，通过该接口下的方法就能获取某种类型的所有 Bean；
• HierarchicalBeanFactory：Hierarchical 意为“层次化”，通常表示一种具有层级结构的概念或组织方式，这种层次化结构可以通过父子关系来表示对象之间的关联，比如树、图、文件系统、组织架构等。根据该接口下的方法可知，能够获取到父容器，说明 BeanFactory 有父子容器概念；
• AutowireCapableBeanFactory：提供了创建 Bean、自动装配 Bean、属性填充、Bean 初始化、依赖注入等能力，比如 @Autowired 注解的底层实现就依赖于该接口的 resolveDependency() 方法；
• ConfigurableBeanFactory：该接口并未直接继承至 BeanFactory，而是继承了 HierarchicalBeanFactory。

BeanFactory不会：

• 主动调用 BeanFactory 后置处理器；
• 主动添加 Bean 后置处理器；
• 主动初始化单例对象；
• 解析 ${} 和 #{}

DefaultListableBeanFactory

• DefaultListableBeanFactory 实现了 BeanFactory 接口，它能管理 Spring 中所有的 Bean，当然也包含 Spring 容器中的那些单例对象。
• DefaultListableBeanFactory 还继承了 DefaultSingletonBeanRegistry 类，这个类就是用来管理 Spring 容器中的单例对象。
• 通过 DefaultListableBeanFactory#registerBeanDefinition 可以注册bean到容器中

BeanFactoryPostProcessor

BeanFactory后置处理器，典型的有

1

org.springframework.context.annotation.internalConfigurationAnnotationProcessor

比如：internalConfigurationAnnotationProcessor就是用来处理 @Configuration 和 @Bean 注解的，将配置类中定义的 Bean 信息补充到 BeanFactory 中。

BeanPostProcessor

Bean后置处理器，典型的有

1
2

org.springframework.context.annotation.internalAutowiredAnnotationProcessor
org.springframework.context.annotation.internalCommonAnnotationProcessor

前者用于解析 @Autowired 注解，后者用于解析 @Resource 注解，它们都有一个共同的类型 BeanPostProcessor。

1

ConfigurationClassPostProcessor.class

用于解析 @ComponentScan @Bean @Import @ImportResource

1

MapperScannerConfigurer.class

用于解析 @MapperScan

DefaultSingletonBeanRegistry

用来管理 Spring 容器中的单例对象。

1

private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

Map 的 key 就是 Bean 的名字，而 value 是对应的 Bean，即单例对象。

BeanDefinition

BeanDefinition 也是一个接口，它封装了 Bean 的定义，Spring 根据 Bean 的定义，就能创建出符合要求的 Bean。

读取 BeanDefinition 可以通过下列两种类完成：

• BeanDefinitionReader
• ClassPathBeanDefinitionScanner

BeanDefinitionReader

该接口中对 loadBeanDefinitions() 方法进行了多种重载，支持传入一个或多个 Resource 对象、资源位置来加载 BeanDefinition。

它有一系列相关实现，比如：

• XmlBeanDefinitionReader：通过读取 XML 文件来加载；
• PropertiesBeanDefinitionReader：通过读取 properties 文件来加载，此类已经被 @Deprecated 注解标记；

除此之外，还有一个 AnnotatedBeanDefinitionReader，尽管它并不是 BeanDefinition 的子类，但它们俩长得很像，根据其类注释可知：它能够通过编程的方式对 Bean 进行注册，是 ClassPathBeanDefinitionScanner 的替代方案，能读取通过注解定义的 Bean。

ClassPathBeanDefinitionScanner

通过扫描指定包路径下的 @Component 及其派生注解来注册 Bean，是 @ComponentScan 注解的底层实现。

比如 MyBatis 通过继承 ClassPathBeanDefinitionScanner 实现通过 @MapperScan 注解来扫描指定包下的 Mapper 接口。

BeanDefinitionRegistry

AnnotatedBeanDefinitionReader 和 ClassPathBeanDefinitionScanner 中都有一个 BeanDefinitionRegistry 类型的成员变量，它是一个接口，提供了 BeanDefinition 的增加、删除和查找功能。

ApplicationContext

ApplicationContext 除了继承 BeanFactory 外，还继承了：

• MessageSource：使其具备处理国际化资源的能力
• ResourcePatternResolver：使其具备使用通配符进行资源匹配的能力
• EnvironmentCapable：使其具备读取 Spring 环境信息、配置文件信息的能力
• ApplicationEventPublisher：使其具备发布事件的能力
• ListableBeanFactory：提供了获取某种类型的 Bean 集合的能力
• HierarchicalBeanFactory：提供了获取父容器的能力

虽然 ApplicationContext 继承了很多接口，但这些能力的实现是通过一种委派（Delegate）的方式实现的，这种方式也被叫做委派模式。

委派模式：实现获取资源的方式并不是由实现类自身完成，而是交给其内部的一个成员变量完成，这样的方式就是委派（这和对象适配器模式很相似）。在日常编码遇到这样的实现逻辑时，类名可以以 Delegate 结尾。

ApplicationContext的相关实现

• ClassPathXmlApplicationContext：基于 classpath 下的 xml 格式的配置文件来创建Bean
• FileSystemXmlApplicationContext：基于磁盘路径下 xml 格式的配置文件来创建Bean

本质都是利用 XmlBeanDefinitionReader#loadBeanDefinitions 加载Bean

• AnnotationConfigApplicationContext：基于 Java 配置类来创建
• AnnotationConfigServletWebServerApplicationContext：基于 Java 配置类来创建，用于 web 环境

ConfigurableApplicationContext

ApplicationContext 有一个子接口 ConfigurableApplicationContext，从类名就可以看出，它提供了对 ApplicationContext 进行配置的能力，浏览其内部方法可知，提供了诸如设置父容器、设置 Environment 等能力。

AbstractApplicationContext

ApplicationContext 有一个非常重要的抽象实现 AbstractApplicationContext，其他具体实现都会继承这个抽象实现，在其内部通过委派的方式实现了一些接口的能力，除此之外还有一个与 Spring Bean 的生命周期息息相关的方法：refresh()。

Bean

生命周期

初始化和销毁 Bean 的实现有三种：

1. 依赖于后置处理器提供的拓展功能
2. 相关接口的功能
3. 使用 @Bean 注解中的属性进行指定

当同时存在以上三种方式时，它们的执行顺序也将按照上述顺序进行执行。

通过实现以下 BeanPostProcessor 接口，可以增强 Bean

• InstantiationAwareBeanPostProcessor
• DestructionAwareBeanPostProcessor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

@Slf4j
@Component
public class MyBeanPostProcessor implements InstantiationAwareBeanPostProcessor, DestructionAwareBeanPostProcessor {

    @Override
    public void postProcessBeforeDestruction(Object o, String beanName) throws BeansException {
        if ("lifeCycleBean".equals(beanName)) {
            log.info("<<<<<<<<<< 销毁执行之前，如 @PreDestroy");
        }
    }

    @Override
    public Object postProcessBeforeInstantiation(Class<?> beanClass, String beanName) throws BeansException {
        if ("lifeCycleBean".equals(beanName)) {
            log.info("<<<<<<<<<< 实例化之前执行，这里返回的对象会替换掉原本的 bean");
        }
        return null;
    }

    @Override
    public boolean postProcessAfterInstantiation(Object bean, String beanName) throws BeansException {
        if ("lifeCycleBean".equals(beanName)) {
            log.info("<<<<<<<<<< 实例化之后执行，如果返回 false 会跳过依赖注入节点");
            // return false;
        }
        return true;
    }

    @Override
    public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) throws BeansException {
        if ("lifeCycleBean".equals(beanName)) {
            log.info("<<<<<<<<<< 依赖注入阶段执行，如 @Autowired、@Value、@Resource");
        }
        return pvs;
    }

    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if ("lifeCycleBean".equals(beanName)) {
            log.info("<<<<<<<<<< 初始化执行之前，这里返回的对象会替换掉原本的 bean，如 @PostConstruct、@ConfigurationProperties");
        }
        return bean;
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if ("lifeCycleBean".equals(beanName)) {
            log.info("<<<<<<<<<< 初始化之后执行，这里返回的对象会替换掉原本的 bean，如代理增强");
        }
        return bean;
    }
}
---------------------------------------------------------------------------------------------
输出：
    
indi.mofan.bean.a03.MyBeanPostProcessor  : <<<<<<<<<< 实例化之前执行，这里返回的对象会替换掉原本的 bean
indi.mofan.bean.a03.LifeCycleBean        : 构造
indi.mofan.bean.a03.MyBeanPostProcessor  : <<<<<<<<<< 实例化之后执行，如果返回 false 会跳过依赖注入节点
indi.mofan.bean.a03.MyBeanPostProcessor  : <<<<<<<<<< 依赖注入阶段执行，如 @Autowired、@Value、@Resource
indi.mofan.bean.a03.LifeCycleBean        : 依赖注入: D:\environment\JDK1.8
indi.mofan.bean.a03.MyBeanPostProcessor  : <<<<<<<<<< 初始化执行之前，这里返回的对象会替换掉原本的 bean，如 @PostConstruct、@ConfigurationProperties
indi.mofan.bean.a03.LifeCycleBean        : 初始化
indi.mofan.bean.a03.MyBeanPostProcessor  : <<<<<<<<<< 初始化之后执行，这里返回的对象会替换掉原本的 bean，如代理增强
indi.mofan.bean.a03.MyBeanPostProcessor  : <<<<<<<<<< 销毁执行之前，如 @PreDestroy
indi.mofan.bean.a03.LifeCycleBean        : 销毁

设计模式

为什么实现了 BeanPostProcessor 接口后就能够在 Bean 生命周期的各个阶段进行拓展呢？

因为使用了模板方法设计模式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

static class MyBeanFactory {
    public Object getBean() {
        Object bean = new Object();
        System.out.println("构造 " + bean);
        System.out.println("依赖注入 " + bean);
        for (BeanPostProcessor processor : processors) {
            processor.inject(bean);
        }
        System.out.println("初始化 " + bean);
        return bean;
    }

    private List<BeanPostProcessor> processors = new ArrayList<>();

    public void addProcessor(BeanPostProcessor processor) {
        processors.add(processor);
    }
}


// 之后如果需要拓展，调用 MyBeanFactory 实例的 addProcessor() 方法添加拓展逻辑即可：
public static void main(String[] args) {
    MyBeanFactory beanFactory = new MyBeanFactory();
    beanFactory.addProcessor(bean -> System.out.println("解析 @Autowired"));
    beanFactory.addProcessor(bean -> System.out.println("解析 @Resource"));
    beanFactory.getBean();
}

@ConfigurationProperties 注解

使用 @ConfigurationProperties 可以指定配置信息的前缀，使得配置信息的读取更加简单。

AutowiredAnnotationBeanPostProcessor

用于解析 @Autowired 和 @Value 注解

AutowiredAnnotationBeanPostProcessor#postProcessProperties()方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Override
public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) {
    InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
    try {
        metadata.inject(bean, beanName, pvs);
    }
    catch (BeanCreationException ex) {
        throw ex;
    }
    catch (Throwable ex) {
        throw new BeanCreationException(beanName, "Injection of autowired dependencies failed", ex);
    }
    return pvs;
}

其中的 findAutowiringMetadata() 用于查找指定的 bean 对象中哪些地方使用了 @Autowired、@Value 等与注入相关的注解，并将这些信息封装在 InjectionMetadata 对象中，之后调用其 inject() 方法利用反射完成注入。

InjectionMetadata 对象中有一个名为 injectedElements 的集合类型成员变量，根据上图所示，injectedElements 存储了被相关注解标记的成员变量、方法的信息，因为 Bean1 中的 bean3 成员变量、setBean2() 和 setHome() 方法恰好被 @Autowired 注解标记。

Scope

Scope 用于指定 Bean 的作用范围，有如下五个取值：

1. singleton：单例（默认值）。容器启动时创建（未设置延迟），容器关闭时销毁
2. prototype：多例。每次使用时创建，不会自动销毁，需要调用 DefaultListableBeanFactory#destroyBean() 进行销毁
3. request：作用于 Web 应用的请求范围。每次请求用到此 Bean 时创建，请求结束时销毁
4. session：作用于 Web 应用的会话范围。每个会话用到此 Bean 时创建，会话结束时销毁
5. application：作用于 Web 应用的 ServletContext。Web 容器用到此 Bean 时创建，容器关闭时销毁

application 的作用范围是 ServletContext，要想 application scope 发生变化可以重启程序。

Aware 接口

Aware 接口用于注入一些与容器相关的信息，比如：

• BeanNameAware 注入 Bean 的名字
• BeanFactoryAware 注入 BeanFactory 容器
• ApplicationContextAware 注入 ApplicationContext 容器
• EmbeddedValueResolverAware 解析 ${}

1. Aware 接口提供了一种 内置 的注入手段，可以注入 BeanFactory、ApplicationContext；
2. InitializingBean 接口提供了一种 内置 的初始化手段；
3. 内置的注入和初始化不受拓展功能的影响，总会被执行，因此 Spring 框架内部的类总是使用这些接口。

Aware 相关接口

BeanNameAware, ApplicationContextAware

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/**
 * @author mofan
 * @date 2023/1/8 16:12
 */
@Slf4j
public class MyBean implements BeanNameAware, ApplicationContextAware {
    @Override
    public void setBeanName(String name) {
        log.info("当前 Bean: " + this + "名字叫: " + name);
    }

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        log.info("当前 Bean: " + this + "容器是: " + applicationContext);
    }
}

InitializingBean

1
2
3
4
5
6
7
8
9

@Slf4j
public class MyBean implements BeanNameAware, ApplicationContextAware, InitializingBean {
    // --snip--

    @Override
    public void afterPropertiesSet() throws Exception {
        log.info("当前 Bean: " + this + " 初始化");
    }
}

当同时实现 Aware 接口和 InitializingBean 接口时，会先执行 Aware 接口。

BeanFactoryAware 、ApplicationContextAware 和 EmbeddedValueResolverAware 三个接口的功能可以使用 @Autowired 注解实现，InitializingBean 接口的功能也可以使用 @PostConstruct 注解实现，为什么还要使用接口呢？

为何有这些接口

@Autowired 和 @PostConstruct 注解的解析需要使用 Bean 后置处理器，属于拓展功能，而这些接口属于内置功能，不加任何拓展 Spring 就能识别。在某些情况下，拓展功能会失效，而内容功能不会失效。

对于 context.refresh(); 方法来说，它主要按照以下顺序干了三件事：

1. 执行 BeanFactory 后置处理器；
2. 添加 Bean 后置处理器；
3. 创建和初始化单例对象。

失效场景

当 Java 配置类中定义了BeanFactoryPostProcessor 时，如果要创建配置类中的 BeanFactoryPostProcessor 就必须 提前 创建和初始化 Java 配置类。

在创建和初始化 Java 配置类时，由于 BeanPostProcessor 还未准备好，无法解析配置类中的 @Autowired 等注解，导致 @Autowired 等注解失效：

具体场景参考博客。

如果一个单例对象的成员变量是多例，怎么办才能在getBean的时候，获取的成员变量是多例的

eg：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// class1
@Component
@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
public class F1 {
}

// class2
@Getter
@Component
public class E {
    @Autowired
    private F1 f1;
}

// main
@Slf4j
@ComponentScan("indi.mofan.bean.a09")
public class A09Application {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(A09Application.class);

        E e = context.getBean(E.class);
        log.info("{}", e.getF1());
        log.info("{}", e.getF1());
        log.info("{}", e.getF1());

        context.close();
    }
}
----------------------------------------------------------------------------------------
// 输出的F1为同一个

原因：对于单例对象来说，依赖注入仅发生了一次，后续不会再注入其他的 f1，因此 e 始终使用的是第一次注入的 f1

解决：

1. 可以使用 @Lazy 注解，因为 @Lazy 生成的是代理对象，虽然代理对象依旧是同一个，但每次使用代理对象中的方法时，会由代理对象创建新的目标对象
2. 其他推荐方式（Object工程、Context容器）参考博客

AOP

前置基础

1. aop的实现方式（除jdk、cglib外的实现方式）
2. aop源码、原理

以上参考博客（9-13）：

https://mofan212.github.io/posts/Spring-Forty-Nine-Lectures-AOP/

Pointcut（切点）

在 Spring 中，切点通过接口 org.springframework.aop.Pointcut 来表示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public interface Pointcut {

/**
 * 根据类型过滤
 */
ClassFilter getClassFilter();

/**
 * 根据方法匹配
 */
MethodMatcher getMethodMatcher();


/**
 * Canonical Pointcut instance that always matches.
 */
Pointcut TRUE = TruePointcut.INSTANCE;

}

Pointcut 接口有很多实现类，比如：

• AnnotationMatchingPointcut：通过注解进行匹配
• AspectJExpressionPointcut：通过 AspectJ 表达式进行匹配（本节的选择）
• StaticMethodMatcherPointcut：通过注解进行匹配（视频中匹配 @Transactional 时使用）

无论是 AspectJExpressionPointcut 还是 StaticMethodMatcherPointcut，它们都实现了 MethodMatcher 接口，用来执行方法的匹配。

AspectJExpressionPointcut

判断编写的 AspectJ 表达式是否与某一方法匹配可以使用其 matches() 方法。

StaticMethodMatcherPointcut

@Transactional 是 Spring 中使用频率非常高的注解，那它底层是通过 AspectJExpressionPointcut 与 @annotation() 切点表达式相结合对目标方法进行匹配的吗？

答案是否定的。@Transactional 注解除了可以作用在方法上，还可以作用在类（或接口）上。

在底层 @Transactional 注解的匹配使用到了 StaticMethodMatcherPointcut

Advice（通知）

MethodInterceptor：这个接口实现的通知属于环绕通知。

Aspect（切面）

DefaultPointcutAdvisor：创建这种切面时，传递一个节点和通知。

/*

• 多个切面：

• aspect =

• 通知 1 （advice） + 切点 1（pointcut）

• 通知 2 （advice） + 切点 2（pointcut）

• 通知 3 （advice） + 切点 3（pointcut）

• …

• advisor = 更细粒度的切面，包含一个通知和切点

• */

ProxyFactory

Spring 是根据什么信息来选择不同的动态代理实现呢？

ProxyFactory 的父类 ProxyConfig 中有个名为 proxyTargetClass 的布尔类型成员变量：

• 当 proxyTargetClass == false，并且目标对象所在类实现了接口时，将选择 JDK 动态代理；
• 当 proxyTargetClass == false，但目标对象所在类未实现接口时，将选择 CGLib 动态代理；
• 当 proxyTargetClass == true，总是选择 CGLib 动态代理。

1
2
3
4

// 设置实现的接口
factory.setInterfaces(target.getClass().getInterfaces());
// 设置proxyTargetClass 
factory.setProxyTargetClass(true);

ProxyFactory 是用来创建代理的核心实现，使用 AopProxyFactory 选择具体的代理实现：

• JdkDynamicAopProxy
• ObjenesisCglibAopProxy

AopProxyFactory 根据 proxyTargetClass 等设置选择 AopProxy 实现，AopProxy 通过 getProxy() 方法创建代理对象。

上述类图中的类与接口都实现了 Advised 接口，能够获得关联的切面集合与目标（实际上是从 ProxyFactory 中获取的）。

调用代理方法时，会借助 ProxyFactory 统一将通知转换为环绕通知 MethodInterceptor。。

AnnotationAwareAspectJAutoProxyCreator

Bean 后置处理器。尽管它的名称中没有 BeanPostProcessor 的字样，但它确实是实现了 BeanPostProcessor 接口的。

AnnotationAwareAspectJAutoProxyCreator 有两个主要作用：

1. 找到容器中所有的切面，针对高级切面，将其转换为低级切面；
2. 根据切面信息，利用 ProxyFactory 创建代理对象。

AnnotationAwareAspectJAutoProxyCreator 实现了 BeanPostProcessor，可以在 Bean 生命周期中的一些阶段对 Bean 进行拓展。AnnotationAwareAspectJAutoProxyCreator 可以在 Bean 进行 依赖注入之前、Bean 初始化之后 对 Bean 进行拓展。

重点介绍 AnnotationAwareAspectJAutoProxyCreator 中的两个方法：

• findEligibleAdvisors
• wrapIfNecessary

findEligibleAdvisors

位于父类 AbstractAdvisorAutoProxyCreator 中，用于找到符合条件的切面类。低级切面直接添加，高级切面转换为低级切面再添加。

findEligibleAdvisors() 方法接收两个参数：

• beanClass：配合切面使用的目标类 Class 信息
• beanName：当前被代理的 Bean 的名称

wrapIfNecessary

wrapIfNecessary() 方法内部调用了 findEligibleAdvisors() 方法，若 findEligibleAdvisors() 方法返回的集合不为空，则表示需要创建代理对象。

如果需要创建对象，wrapIfNecessary() 方法返回的是代理对象，否则仍然是原对象。

wrapIfNecessary() 方法接收三个参数：

• bean：原始 Bean 实例
• beanName：Bean 的名称
• cacheKey：用于元数据访问的缓存 key

@Order

根据上述打印的信息可知，低级切面相比于高级切面先一步被执行，这个执行顺序是可以被控制的。

针对高级切面来说，可以在类上使用 @Order 注解

在高级切面中，@Order 只有放在类上才生效，放在方法上不会生效。比如高级切面中有多个前置通知，这些前置通知对应的方法上使用 @Order 注解是无法生效的。

针对低级切面，需要设置 advisor 的 order 值，而不是向高级切面那样使用 @Order 注解，使用 @Order 注解设置在 advisor3() 方法上是无用的。

代理对象创建时机

使用 AnnotationAwareAspectJAutoProxyCreator Bean 后置处理器创建代理对象的时机有以下两个选择：

• Bean 的依赖注入之前
• Bean 初始化完成之后

代理对象的创建时机：

• 无循环依赖时，在 Bean 初始化阶段之后创建；
• 有循环依赖时，在 Bean 实例化后、依赖注入之前创建，并将代理对象暂存于二级缓存。

Bean 的依赖注入阶段和初始化阶段不应该被增强，仍应被施加于原始对象。

高级切面转低级切面

调用 AnnotationAwareAspectJAutoProxyCreator 对象的 findEligibleAdvisors() 方法时，获取能配合目标 Class 使用的切面，最终返回 Advisor 列表。在搜索过程中，如果遇到高级切面，则会将其转换成低级切面。

以解析 @Before 注解为例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public static void main(String[] args) throws Throwable {
    // 切面对象实例工厂，用于后续反射调用切面中的方法
    AspectInstanceFactory factory = new SingletonAspectInstanceFactory(new Aspect());
    // 高级切面转低级切面类
    List<Advisor> list = new ArrayList<>();
    for (Method method : Aspect.class.getDeclaredMethods()) {
        if (method.isAnnotationPresent(Before.class)) {
            // 解析切点
            String expression = method.getAnnotation(Before.class).value();
            AspectJExpressionPointcut pointcut = new AspectJExpressionPointcut();
            pointcut.setExpression(expression);
            // 通知类。前置通知对应的通知类是 AspectJMethodBeforeAdvice
            AspectJMethodBeforeAdvice advice = new AspectJMethodBeforeAdvice(method, pointcut, factory);
            // 切面（advice转换成advisor）
            Advisor advisor = new DefaultPointcutAdvisor(pointcut, advice);
            list.add(advisor);
        }
    }
    for (Advisor advisor : list) {
        System.out.println(advisor);
    }
}

@Before 标记的前置通知会被转换成原始的 AspectJMethodBeforeAdvice 形式，该对象包含了以下信息：

• 通知对应的方法信息
• 切点信息
• 通知对象如何创建，本例公用一个 Aspect 对象

静态通知调用

详情见参考博客

动态通知调用

详情见参考博客

MVC

RequestMappingHandlerMapping

HandlerMapping，即处理器映射器，用于建立请求路径与控制器方法的映射关系。

RequestMappingHandlerMapping 是 HandlerMapping 的一种实现，根据类名可知，它是通过 @RequestMapping 注解来实现路径映射。

当 Spring 容器中没有 HandlerMapping 的实现时，尽管 DispatcherServlet 在初始化时会添加一些默认的实现，但这些实现不会交由 Spring 管理，而是作为 DispatcherServlet 的成员变量。

RequestMappingHandlerAdapter

RequestMappingHandlerAdapter 实现了 HandlerAdapter 接口，HandlerAdapter 用于执行控制器方法，而 RequestMapping 表明 RequestMappingHandlerAdapter 用于执行被 @RequestMapping 注解标记的控制器方法。

实现控制器方法的调用很简单，但如何将请求参数与方法参数相绑定的呢？

显然是需要解析 @RequestParam 注解。

Spring 支持许多种类的控制器方法参数，不同种类的参数使用不同的解析器，使用 RequestMappingHandlerAdapter 的 getArgumentResolvers() 方法获取所有参数解析器。

Spring 也支持许多种类的控制器方法返回值类型，使用 RequestMappingHandlerAdapter 的 getReturnValueHandlers() 方法获取所有返回值处理器。

参数解析器

@RequestParam

@RequestParam 注解的解析需要使用到 RequestParamMethodArgumentResolver 参数解析器。构造时需要两个参数：

• beanFactory：Bean 工厂对象。需要解析 ${} 时，就需要指定 Bean 工厂对象
• useDefaultResolution：布尔类型参数。为 false 表示只解析添加了 @RequestParam 注解的参数，为 true 针对未添加 @RequestParam 注解的参数也使用该参数解析器进行解析。

RequestParamMethodArgumentResolver 利用 resolveArgument() 方法完成参数的解析，该方法需要传递四个参数：

• parameter：参数对象
• mavContainer：ModelAndView 容器，用来存储中间的 Model 结果
• webRequest：由 ServletWebRequest 封装后的请求对象
• binderFactory：数据绑定工厂，用于完成对象绑定和类型转换，比如将字符串类型的 18 转换成整型

@PathVariable

@PathVariable 注解的解析需要使用到 PathVariableMethodArgumentResolver 参数解析器。构造时无需传入任何参数。

使用该解析器需要一个 Map 集合，该 Map 集合是 @RequestMapping 注解上指定的路径和实际 URL 路径进行匹配后，得到的路径上的参数与实际路径上的值的关系（获取这个 Map 并将其设置给 request 作用域由 HandlerMapping 完成）。

@RequestHeader

@RequestHeader 注解的解析需要使用到 RequestHeaderMethodArgumentResolver 参数解析器。构造时需要传入一个Bean 工厂对象。

@CookieValue

@CookieValue 注解的解析需要使用到 ServletCookieValueMethodArgumentResolver 参数解析器。构造时需要传入一个Bean 工厂对象。

@Value

@Value 注解的解析需要使用到 ExpressionValueMethodArgumentResolver 参数解析器。构造时需要传入一个Bean 工厂对象。

HttpServletRequest

HttpServletRequest 类型的参数的解析需要使用到 ServletRequestMethodArgumentResolver 参数解析器。构造时无需传入任何参数。

ServletRequestMethodArgumentResolver 参数解析器不仅可以解析 HttpServletRequest 类型的参数，还支持许多其他类型的参数，其支持的参数类型可在 supportsParameter() 方法中看到：

@ModelAttribute

@ModelAttribute 注解的解析需要使用到 ServletModelAttributeMethodProcessor 参数解析器。构造时需要传入一个布尔类型的值。为 false 时，表示 @ModelAttribute 不是不必须的，即是必须的。

针对 @ModelAttribute(“abc”) User user1 和 User user2 两种参数来说，尽管后者没有使用 @ModelAttribute 注解，但它们使用的是同一种解析器。

添加两个 ServletModelAttributeMethodProcessor 参数解析器，先解析带 @ModelAttribute 注解的参数，再解析不带 @ModelAttribute 注解的参数。

通过 ServletModelAttributeMethodProcessor 解析得到的数据还会被存入 ModelAndViewContainer 中。存储的数据结构是一个 Map，其 key 为 @ModelAttribute 注解指定的 value 值，在未显式指定的情况下，默认为对象类型的首字母小写对应的字符串。

@RequestBody User user3 参数也被 ServletModelAttributeMethodProcessor 解析了，如果想使其数据通过 JSON 数据转换而来，则需要使用另一个参数解析器。

@RequestBody

@RequestBody 注解的解析需要使用到 RequestResponseBodyMethodProcessor 参数解析器。构造时需要传入一个消息转换器列表。

1

先添加解析 @ModelAttribute 注解的解析器，再添加解析 @RequestBody 注解的解析器，最后添加解析省略了 @ModelAttribute 注解的解析器。如果更换最后两个解析器的顺序，那么 @RequestBody User user3 将会被 ServletModelAttributeMethodProcessor 解析，而不是 RequestResponseBodyMethodProcessor。

获取参数名

DefaultParameterNameDiscoverer

1
2
3
4
5
6
7
8
9
10
11

public class DefaultParameterNameDiscoverer extends PrioritizedParameterNameDiscoverer {

   public DefaultParameterNameDiscoverer() {
      if (KotlinDetector.isKotlinReflectPresent() && !NativeDetector.inNativeImage()) {
         addDiscoverer(new KotlinReflectionParameterNameDiscoverer());
      }
      addDiscoverer(new StandardReflectionParameterNameDiscoverer());
      addDiscoverer(new LocalVariableTableParameterNameDiscoverer());
   }

}

需要获取参数名称的原因：（java编译的时候，如果不加-par-parameters 即不是【javac -parameters .\Bean2.java】编译的，则不会保留参数名称）

在项目的 src 目录外创建一个 Bean2.java 文件，使其不会被 IDEA 自动编译

1
2
3
4
5
6
7

package indi.mofan.a22;

public class Bean2 {
    public void foo(String name, int age) {

    }
}

将命令行切换到 Bean2.java 文件所在目录的位置，执行 javac .\Bean2.java 命令手动编译 Bean2.java。查看 Bean2.class 文件的内容

1
2
3
4
5
6
7
8
9

package indi.mofan.a22;

public class Bean2 {
    public Bean2() {
    }

    public void foo(String var1, int var2) {
    }
}

编译生成的 class 文件中的 foo() 方法的参数名称不再是 name 和 age，也就是说直接使用 javac 命令进行编译得到的字节码文件不会保存方法的参数名称。

10. 覆盖quals时请遵守通用规定

尽管Object是一个具体类，但设计它主要是为了扩展。它所有的非final方法（equals、hashCode、toString、clone和finalize）都有明确的通用约定（general contract），因为它们设计成是要被覆盖（override）的。任何任何一个类，它在覆盖这些方法的时候，都有责任遵守这些通用约定；如果不能做到这一点，其他依赖于这些约定的类（例如HashMap和HashSet）就无法结合该类一起正常运作。

本章将讲述何时以及如何覆盖这些非final的Object方法。本章不再讨论finalize方法，因为第8条已经讨论过这个方法了。而Comparable.compareTo虽然不是Object方法，但是本章也将对其进行讨论，因为它具有类似的特点。

覆盖 equals 方法看起来似乎很简单，但是有许多覆盖方式会导致错误，并且后果非常严重。最容易避免这类问题的办法就是不覆盖 equals 方法，在这种情况下，类的每个实例都只与它自身相等。如果满足了以下任何一个条件，就可以不覆盖 equals 方法：

• 类的每个实例本质上都是唯一的。对于代表活动实体而不是值（value）的类来说确实如此，例如 Thread。Object 提供的 equals 实现对于这些类来说正是正确的行为。
• 类没有必要提供“逻辑相等”的测试功能。例如，java.util.regex.Pattern 可以覆盖 equals，以检查两个 Pattern 实例是否代表同一个正则表达式，但是设计者并不认为客户需要或者期望这样的功能。在这类情况之下，从 Object 继承得到的 equals 实现已经足够了。

超类已经覆盖了 equals，超类的行为对于这个类也是合适的。例如，大多数的 Set 实现从 AbstractSet 继承 equals 实现，List 实现从 AbstractList 继承 equals 实现，Map 实现从 AbstractMap 继承 equals 实现。

类是私有的，或者是包级私有的，可以确定它的 equals 方法永远不会被调用。如果你非常想规避风险，可以覆盖 equals 方法，确保它不会被意外调用：

1
2
3

@Override public boolean equals(Object o) {
throw new AssertionError(); // Method is never called
}

那么什么时候应该覆盖 equals 方法呢？

如果类具有自己特有的“逻辑相等”概念（不同于对象等同的概念），而且超类还没有覆盖 equals。这通常属于“值类”(value class)的情形。值类仅仅是一个表示值的类，例如 Integer 或者 String。程序员在利用 equals 方法来比较值对象的引用时，希望知道它们在逻辑上是否相等，而不是了解它们是否指向同一个对象。为了满足程序员的要求，不仅必须覆盖 equals 方法，而且这样做也使得这个类的实例可以用作映射表(map)的键(key)，或者集合(set)的元素，使映射或者集合表现出预期的行为。

在覆盖 equals 方法的时候，必须要遵守它的通用约定。下面是约定的内容，来自 Object 的规范。

equals 方法实现了等价关系，其属性如下：

• 自反性(reflexive)：对于任何非 null 的引用值 x，x.equals(x) 必须返回 true。
• 对称性(symmetric)：对于任何非 null 的引用值 x 和 y，当且仅当 y.equals(x) 返回 true 时，x.equals(y) 必须返回 true。
• 传递性(transitive)：对于任何非 null 的引用值 x、y 和 z，如果 x.equals(y) 返回 true，并且 y.equals(z) 也返回 true，那么 x.equals(z) 也必须返回 true。
• 一致性(consistent)：对于任何非 null 的引用值 x 和 y，只要 equals 的比较操作在对象中所用的信息没有被修改，多次调用 x.equals(y) 就会一致地返回 true，或者一致地返回 false。
• 对于任何非 null 的引用值 x，x.equals(null) 必须返回 false。

实现高质量 equals 方法的诀窍：

1. 使用 == 操作符检查“参数是否为这个对象的引用”。 如果是，则返回 true。 这只不过是一种性能优化，如果比较操作有可能很昂贵，就值得这么做。
2. 使用 instanceof 操作符检查“参数是否为正确的类型”。 如果不是，则返回 false 一般说来，所谓“正确的类型”是指equals 方法所在的那个类。 某些情况下，是指该类所实现的某个接口。 如果类实现的接口改进了 equals 约定，允许在实现了该接口的类之间进行比较，那么就使用接口。 集合接口如Set、List、Map和Map.E口try具有这样的特性。
3. 把参数转换成正确的类型。 因为转换之前进行过且stanceof测试，所以确保会成功。
4. 对于该类中的每个“关键”（ significant ）域，检查参数中的域是否与该对象中对应的域相匹配。 如果这些测试全部成功，则返回 true；否则返回 false。 如果第2步中的类型是个接口，就必须通过接口方法访问参数中的域；如果该类型是个类，也许就能够直接访问参数中的域，这要取决于它们的可访问性。
5. 在编写完 equals 方法之后，应该问自己三个问题：它是否是对称的、传递的、一致的？ 并且不要只是自问，还要编写单元测试来检验这些特性

下面是最后的一些告诫：

• 覆盖equals 时总要覆盖hashCode

• 不要企图让equals 方法过于智能。 如果只是简单地测试域中的值是否相等，则不难做到遵守 equals 约定。 如果想过度地去寻求各种等价关系，则很容易陷入麻烦之中。把任何一种别名形式考虑到等价的范围内，往往不会是个好主意。 例如，File类不应该试图把指向同一个文件的符号链接（symbolic link）当作相等的对象来看待。 所幸File 类没有这样做

• 不要将equals 声明中的 Object 对象替换为其他的类型。 比如：

  // Broken - parameter type must be Object!
  public boolean equals(MyClass o) {
  …
  }

  问题在于，这个方法并没有覆盖 Object. equals，因为它的参数应该 是Object 类型，相反，它重载了 Object.equals。 在正常 equals 方法的基础上，再提供一个“强类型”的 equals 方法。

  增加@Override注解可以在编译前发现问题

  // Still broken, but won’t compile
  @Override
  public boolean equals(MyClass o) {
  …
  }

• 编写和测试 equals（及hashCode）方法都是十分繁琐的，得到的代码也很琐碎。 代替手工编写和测试这些方法的最佳途径，是使用Google开源的AutoValue框架，它会自动替你生成这些方法，通过类中的单个注解就能触发。 在大多数情况下，AutoValue生成的方法本质上与你亲自编写的方法是一样的。

总之，除非必须，否则不要覆盖 equals 方法：在许多情况下，从 Object 继承而来的实现正是你想要的。如果你确实覆盖了 equals，那么一定要比较类的所有重要字段，并以保留 equals 约定的所有 5 项规定的方式进行比较。

11. 覆盖equals时总要覆盖hashCode

在每一个覆盖了equals方法的类中，总要覆盖hashCode方法。如果不这样做的话，就会违反hashCode的通用约定，

Object规范：

• 在应用程序的执行期间，只要对象的equals方法的比较操作所用到的信息没有被修改，那么对同一个对象的多次调用，hashCode方法都必须始终返回同一个值。在一个应用程序与另一个程序的执行过程中，执行hashCode方法所返回的值可以不一致。
• 如果两个对象根据equals(Object）方法比较是相等的，那么调用这两个对象中的hashCode方法都必须产生同样的整数结果。
• 如果两个对象根据equals(Object）方法比较是不相等的，那么调用这两个对象中的hashCode方法，则不一定要求hashCode方法必须产生不同的结果。 但是程序员应该知道，给不相等的对象产生截然不同的整数结果，有可能提高散列表（hashtable）的性能。

因没有覆盖hashCode 而违反的关键约定是第二条：相等的对象必须具有相等的散到码（ hashcode ）。

比如：

1
2

Map<PhoneNumber, String> m = new HashMap<>();
m.put(new PhoneNumber(707, 867, 5309), "Jenny");

此时，你可能期望 m.get(new PhoneNumber(707, 867,5309)) 返回「Jenny」，但是它返回 null。

注意，这里涉及两个PhoneNumber实例：第一个被插入HashMap中，第二个实例与第一个相等，用于从Map中根据PhoneNumber去获取用户名字。

由于PhoneNumber类没有覆盖hashCode方法，从而导致两个相等的实例具有不相等的散列码，违反了hashCode的约定。因此，put方法把电话号码对象存放在一个散列桶（hash bucket）中，get方法却在另一个散列桶中查找这个电话号码。即使这两个实例正好被放到同一个散列桶中，get方法也必定会返回null，因为HashMap有一项优化，可以将与每个项相关的散列码缓存起来，如果散列码不匹配，也就不再去检验对象的等同性。

修正这个问题十分简单，只需要给PhoneNumber类提供一个适当的hashCode方法即可。

不要试图从散列码计算中排除掉一个对象的关键域来提高性能。 虽然这样得到的散列函数运行起来可能更快，但是它的效果不见得会好，可能会导致散列表慢到根本无法使用。特别是在实践中，散列函数可能面临大量的实例，在你选择忽略的区域之中，这些实例仍然区别非常大。 如果是这样，散列函数就会把所有这些实例映射到极少数的散列码上，原本应 该以线性级时间运行的程序，将会以平方级的时间运行。

不要对hashCode方法的返回值做出具体的规定，因此客户端无法理所当然地依赖它；这样可以为修改提供灵活性。 Java类库中的许多类，比如 String 和 Integer，都可以把 它们的 hashCode 方法返回的确切值规定为该实例值的一个函数。一般来说，这并不是个好主意，因为这样做严格地限制了在未来的版本中改进散列函数的能力。 如果没有规定散列函数的细节，那么当你发现了它的内部缺陷时，或者发现了更好的散列函数时，就可以在后面的发行版本中修正它。

12. 始终要覆盖toString

虽然Object提供了 toString 方法的一个实现，但它返回的字符串通常并不是类的用户所期望看到的。它包含类的名称，以及一个“＠”符号，接着是散列码的无符号十六进制表示法，例如PhoneNumber@163b91。 toString的通用约定指出，被返回的字符串应该是一个“简洁的但信息丰富，并且易于阅读的表达形式”。

• 遵守toString约定并不像遵守 equals 和 hashCode 的约定那么重要，但是，提供好的toString实现可以便类用起来更加舒适，使用了这个类的系统也更易于调试。
• 在实际应用中， toString 方法应该返回对象中包含的所有值得关注的信息。
• 无论是否指定返回值（字符串）格式，都应该在文档注释中明确地表明你的意图。
• 无论是否指定返回值（字符串）格式，都为toString返回值中包含的所有信息提供一种可以通过编程访问到的途径。 即提供方法获取toString中的某一部分数据，而不需要去解析toString。

13. 谨慎地覆盖clone

Cloneable接口的目的是作为对象的UI个mixin接口，表明这样的对象允许克隆。但是这个接口没有定义clone方法，并且Object的clone方法是受保护的。所以，如果不借助反射，就不能仅仅因为一个对象实现了Cloneable接口，就调用clone方法。

Cloneable接口并没有包含任何方法，那么这个接口有什么作用呢？

这个接口是一个标记接口（空接口），他决定了Object中受保护的clone方法实现的行为。如果一个类实现了Cloneable接口，Object的clone方法就返回该对象的浅拷贝；如果没有实现Cloneable接口就会抛出CloneNotSupportedException异常。

【Object的clone方法被 protected 和 native 修饰 （见相关博客）】

事实上，实现Cloneable接口的类都是为了提供一个功能适当的公有的clone方法。

注意事项：

• 不可变的类永远都不应该提供clone方法。它只会激发不必要的克隆。

• clone默认是浅拷贝，如果对象的域引用了可变的对象（数组），需要重写clone方法深拷贝。

• Cloneable架构与引用可变对象的final域的正常用法是不兼容的。clone方法被禁止给final域对象赋新值。

• 公有的clone方法应该省略throws声明。因为不会抛出受检异常的方法使用起来更加轻松。

• 对象拷贝的更好的办法是提供一个拷贝构造器或者拷贝工厂

  1 2 3 4

  // Copy constructor public Yum(Yum yum) { ... }; // Copy factory public static Yum newInstance(Yum yum) { ... };

• 使用clone方法克隆复杂对象的一种方法：首先，调用super.clone方法（归根结底是Object的clone方法，浅拷贝）；然后把对象中的所有域（属性）设置成初始状态，然后调用子类的方法给域（属性）重新赋值。

相关博客：java实现简单的克隆-CSDN博客

14. 考虑实现Comparable接口

实现Comparable接口主要是重写compareTo方法。该方法的目的不但允许进行简单的等同性比较，而且允许执行顺序比较。

1. 如果一个对象没有实现Comparable接口，或者需要使用一个非标准的排序关系，就可以使用一个显示的Comparator来代替，或者编写自己的比较器，或者使用已有的比较器。
2. 在compareTo方法中使用关系操作符<、>（大于号、小于号）是非常繁琐的，并且容易出错，所以不建议使用。应该在装箱基本类型的类中使用静态的compare方法，或者Comparator接口中使用比较器构造方法。

15. 使类和成员的可访问性最小化

区分一个组件设计的好不好，唯一重要的因素是：它对于外部的其他组件而言，是否隐藏了其内部数据和其他细节实现。好的组件会隐藏所有的实现细节，把API与实现清晰地隔离出来，组件之间只通过API进行通信，一个模块不需要知道其他模块的内部工作情况。这种设计也被称为信息隐藏或封装。

Java提供了许多机制来协助信息隐藏。访问控制机制通过访问修饰符决定类、接口和成员的可访问性。

规则：

1. 尽可能地使每个类或者成员不被外界访问

   • 类和接口：只有两种访问级别，包级私有（无修饰）和公有（public修饰）。如果能把类/接口做成包级私有，就需要定义为包级私有。

     如果一个包级私有的顶层类/接口只在某一个类的内部被用到，就应该考虑使它成为唯一使用的类的私有嵌套类

   • 成员（域、方法、嵌套类、嵌套接口）：私有（private）、包级私有（无修饰）、受保护的（protected修饰）、公有（public修饰）

2. 公有类的实例域决不能是公有的。如果公有类的实例域一旦公有，你就等于放弃了对存储在这个域中的值进行限制的能力；并且包含公有可变域的类通常并不是线程安全的。

   让类具有公有的静态final数据域，或者返回这种域的访问方法，是错误的。

16. 要在公有类而非公有域中使用访问方法

对于公有类，他的域尽可能的私有。所以，如果需要访问域时，需要共有类提供访问方法，比如getXXX()。

不过，如果类是包级私有的，或者是私有的嵌套类，直接暴露它的数据域并没有本质的错误。

17. 使可变性最小化

不可变类是指其实例不能被修改的类，每个实例中包含的所有信息都必须在创建该实例的时候就提供，并且在对象的整个生命周期内固定不变。

如果要使类成为不可变类，必须要遵循的规则：

1. 不要提供任何会修改对象状态的方法
2. 保证类不会被拓展（一般是用final声明）
3. 声明所有域都是final的
4. 声明所有域都是私有的
5. 确保对任何可变组件的互斥访问。如果类具有指向可变对象的域，则必须确保该类的客户端无法获得指向这些对象的引用。

不可变类的优点：

1. 不可变类比较简单，只有一种状态，即被创建时的状态。
2. 不可变对象本质是线程安全的，他们不要求同步。
3. 不可变对象可以被自由的共享，甚至可以共享类的内部信息。
4. 不可变对象为其他对象提供了大量的构件。
5. 不可变对象无偿的提供了失败的原子性，不存在临时不一致的可能性。

不可变类的缺点：真正唯一的缺点是对于每个不同的值，都需要一个单独的对象。

类创建原则：

1. 除非有很好的理由要让类成为可变的类，否则他就应该是不可变的。
2. 如果类不能被做成不可变的，仍然应该尽可能地限制他的可变性。
3. 除非有令人信服的理由要使域变成是非final的，否则每个域都应该是private final的。
4. 构造器应该创建完全初始化的对象，并建立起所有的约束关系。

18. 复合优先于继承

本小节的继承指：一个类拓展另一个类的时候。（不考虑一个类实现一个接口或者一个接口扩展另一个接口的时候）

继承是实现代码重用的有利手段，但并非永远是最佳工具。

因为和方法调用不同，继承打破了封装性。子类依赖于其超类中特定功能的实现细节。超类的实现有可能会随着发行版本的不同而有所变化，如果真的发生了变化，子类可能会遭到破坏，即使它的代码完全没有改变。 因而，子类必须要跟着其 超类的更新而演变，除非超类是专门为了扩展而设计的，并且具有很好的文挡说明。

只有当子类真正是超类的子类型时，才适合用继承。

复合：不扩展现有类，而是在新的类中增加一个私有域，引用现有类的一个实例。新类中的每个实例方法都可以调用被包含的先有类中对应的方法，并返回它的结果。这被称为转发，新类中的方法被称为转发方法。

19. 要么设计继承并提供文档说明，要么禁止继承

对于专门为了继承而设计并且具有良好文档说明的类而言：

1. 该类必须有文档说明它可覆盖的方法的自用型

好的API文档应该描述一个给定的方法做了什么工作，而不是描述它是如何做到的。

1. 类必须以精心挑选的受保护的方法的形式，提供适当的钩子（hook），以便进入其内部工作中。

钩子（hook）：允许程序员在程序运行的不同阶段插入额外的代码，以实现对程序行为的控制和定制化。JAVA中的hook通常通过回调函数或者监听器的方式实现。当程序到达某个特定的状态或者事件发生时，钩子会触发相应的回调函数或者事件处理方法，从而执行额外的逻辑。

1. 对于为了继承而设计的类，唯一的测试方式就是编写子类。换句话说，必须在发布类之前先编写子类对类进行测试。
2. 构造器决不能调用可被覆盖的方法。
3. 如果类实现了Cloneable或者Serializable接口，无论是clone还是readObject方法，都不可以调用可覆盖的方法，不管是以直接还是间接的方式。
4. 对于那些并非为了安全地进行子类化而设计和编写文档的类，要禁止子类化。

20. 接口优于抽象类

Java提供了两种机制，可以用来定义允许多个实现的类型：接口和抽象类。并且Java 8以后，接口引入了缺省方法。这两种机制都允许为某些实例方法提供实现。

1. 现有的类可以很容易被更新，以实现新的接口

2. 接口是定义mixin（混合类型）的理想选择

   混合类型：类除了实现它的“基本类型”以外，还可以实现mixin类型，以表明它提供了某些可选择的行为。

3. 接口允许构造非层次结构的类型框架

4. 接口使得安全地增强类的功能成为可能（包装类模式）

5. 通过对接口提供一个抽象的骨架实现类（即抽象类实现接口，使用类继承抽象类），可以把接口和抽象类的优点结合起来。接口负责定义类型，也可以提供一些缺省方法，抽象类则负责实现除基本类型接口方法以外的方法。（模板方法模式）

6. 对于骨架实现类而言，好的文档绝对是非常必要的

21. 为后代设计接口

在Java 8发行之前，如果不破坏现有的实现，是不可能给接口添加方法的。如果给某个接口添加了一个新的方法，就会导致编译错误。Java 8以后，增加了缺省方法构造，目的就是允许给现有的接口添加方法。

注意：

1. 并非每一个可能实现的所有变体，始终都可以编写出一个缺省方法
2. 有了缺省方法，接口的现有实现就不会出现编译时没有报错或警告，运行时却失败的情况。
3. 谨慎设计接口仍然是至关重要的

22. 接口只用于定义类型

当类实现接口时，接口就充当可以引用这个类的实例的类型。因此，类实现了接口，就表明客户端可以对这个类的实例实施某些动作。

注意：

1. 常量接口模式是对接口的不良使用

   有一种接口被称为常量接口（constant interface），它不满足上面的条件。这种接口不包含任何方法，它只包含静态的final域，每个域都导出一个常量。使用这些常量的类实现这个接口，以避免用类名来修饰常量名。

2. 如果要导出常量类，可以把这些常量添加到这个类或者接口中，比如Integer的MAX_VALUE；如果这些常量最好被看做枚举类型的成员，就应该用枚举类型；如果不行，应该使用不可实例化的工具类来导出这些常量；如果大量利用工具类导出的常量，可以通过利用静态导入机制，避免使用类名修饰常量名。

23. 类层次优于标签类

标签类过于冗长、容易出错，并且效率低下。

标签类属于类层次的一种

24. 静态成员类优于非静态成员类

嵌套类（nested class）是指指定在另一个类的内部的类。嵌套类存在的目的应该只是为了它的外围（enclosing class）提供服务。如果嵌套类将来可能会用于其他的某个环境中，它就应该顶层类（top-level class）。嵌套类有四种：静态成员类（static member class）、非静态成员类（nonstatic member class）、匿名名（anonymous class）和局部类（local class）。除了第一种之外，其他三种都称为内部类（inner class）。

静态成员类是最简单的一种嵌套类。最好把它看作是普通类，只是碰巧被声明在另一个类的内部而已，它可以访问外围的所有成员，包括那些声明为私有的成员。静态成员类是外围的一个静态成员，与其他的静态成员一样，也遵守同样的可访问性规则。如果它被声明为私有的，它就只能在外围类的内部才能被访问，等等。静态成员类的一种常见用法是作为公有的辅助类，只有与它的外部类一起使用才有意义。

非静态成员类的一种常见用法是定义一个Adapter，它允许外部类的实例被看作是另一个不相关的类的实例。 如果声明成员类不要求访问外围实例，就要始终把修饰符 static 放在它的声明中， 使它应当把嵌套类声明成静态成员类，而不是非静态成员类。如果省略了 static 修饰符，则每个实例都将包含一个额外的指向外围对象的引用。如前所述，保存这份引用要消耗时间和空间，并且会导致外围实例在符合垃圾回收时仍然得以保留。由此造成的内存泄漏可能是灾难性的。但是常常难以发现，因为这个引用是不可见的。

如果相关的类是导出类的公有或受保护的成员，毫无疑问，在静态和非静态成员类之间做出正确的选择是非常重要的。在这种情况下，该成员类就是导出的 API 元素，在后续的发行版本中，如果不违背向后兼容性，就无法从非静态成员类变为静态成员类。

匿名类是没有名字的。它不是外围类的一个成员。它并非与其他的成员一起被声明，而是在使用的同时被声明和实例化。匿名类可以出现在代码中任何允许存在表达式的地方。当且仅当匿名类出现在非静态的环境中时，它才拥有外围实例。但是即使它们出现在静态的环境中，也不可能拥有任何静态成员，而是拥有常数变量（constant variable），常数变量是 final 基本类型，或者是被初始化为常量表达式[JLS, 4.12.4]的字符串字面量。

匿名类的运用受到诸多的限制。除了在它们被声明的时候之外，是无法将它们实例化的。不能执行 instanceof 测试，或者做任何需要命名类的其他事情。无法声明一个匿名类来实现多个接口，或者扩展一个类，并同时扩展类和实现接口。除了从超类型继承得到之外，匿名类的客户端无法调用任何成员。由于匿名类出现在表达式中，它们必须保持简短（大约 10 行或者更少），否则会影响程序的可读性。

局部类是四种嵌套类中使用最少的类。在任何“可以声明局部变量”的地方，都可以声明局部类，并且局部类也遵守同样的作用域规则。局部类与其他三种嵌套类中的每一种都有一些共同的属性。与成员类一样，局部类有名字，可以被重复使用。与匿名类一样，只有当局部类是在非静态态环境中定义的时候，才有外围实例，它们也不能包含静态成员。与匿名类一样，它们必须非常简短以便不会影响可读性。

总而言之，共有四种不同的嵌套类，每一种都有自己的用途。如果一个嵌套类需要在单个方法之外仍然是可见的，或者它太长了，不适合放在方法内部，就应该使用成员类。如果成员类的每个实例都需要一个指向其外围实例的引用，就把成员类做成非静态的；否则，就做成静态的。假设这个嵌套类属于一个方法的内部，如果你只需要在一个地方创建实例，并且已经有了一个预设的类型可以说明这个类的特征，就把它做成匿名类；否则，就做成分部类。

25. 限制源文件为单个顶级类

永远不要把多个顶级类或者接口放在一个源文件中。遵循这个规则可以确保编译时一个类不会有多重定义。这么做反过来也能确保编译产生的类文件，以及程序的结果的行为，都不会受到源文件被传送给编译器时的顺序的影响。

1. 以静态工厂方法代替构造函数

客户端获取类实例的方法：

1. 构造器
2. 静态工厂方法

推荐使用静态工厂方法，而不是构造器方法。

静态工厂优点：

1. 静态工厂方法有确切的名称，构造器只能是类名

2. 静态工厂方法可以通过不需要在每次调用时创建新的对象。类似于享元模式

3. 静态工厂方法可以获取返回类型的子类对象

4. 静态工厂方法返回对象的类可以随调用的不同而变化，作为输入参数的函数

   比如：

   构造方法：Map\> m = new HasMap>();

   静态工厂方法：

   public static HashMap newInstance() {

   ​ return new HashMap();

   }

静态工厂缺点：

1. 没有公共或受保护构造函数的类不能被子类化

2. 和其他静态方法实际上没有任何区别

   为了加以区别，静态工厂使用一些惯用名称

   • valueOf：该方法返回的实例和参数的数值相同。实际上是一种类型转换方法
   • of：valueOf的简洁替代
   • getInstance：返回的实例通过参数来描述。对于单例模式，该方法没有参数并返回唯一实例
   • newInstance：多例模式，每次返回新值
   • getType：和getInstance类似，但是在工厂方法处于不同的类中使用
   • newType：和newInstance类似，但是在工厂方法处于不同的类中使用

2. 遇到多个构造器参数时考虑用构建器

静态工厂和构造器有一个共同的缺陷，他们都不能很好的扩展到大量的可选参数。如果一个类新建有大量的可选参数，通常采用重叠构造器模式，多个构造器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

// Telescoping constructor pattern - does not scale well!
public class NutritionFacts {
    private final int servingSize; // (mL) required
    private final int servings; // (per container) required
    private final int calories; // (per serving) optional
    private final int fat; // (g/serving) optional
    private final int sodium; // (mg/serving) optional
    private final int carbohydrate; // (g/serving) optional

    public NutritionFacts(int servingSize, int servings) {
        this(servingSize, servings, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories) {
        this(servingSize, servings, calories, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories, int fat) {
        this(servingSize, servings, calories, fat, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium) {
        this(servingSize, servings, calories, fat, sodium, 0);
    }

    public NutritionFacts(int servingSize, int servings, int calories, int fat, int sodium, int carbohydrate) {
        this.servingSize = servingSize;
        this.servings = servings;
        this.calories = calories;
        this.fat = fat;
        this.sodium = sodium;
        this.carbohydrate = carbohydrate;
    }
}

当创建实例的时候，就需要利于利用参数列表最短的构造器，但是这个列表包含了要设置的所有参数。

重叠构造器模式可行，但是当有许多参数的时候，客户端代码会很难编写，并且仍然难以阅读。如果客户端颠倒参数的位置，有可能编译器也不会报错，但是程序运行时错误。

替代方法二：JavaBeans模式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// JavaBeans Pattern - allows inconsistency, mandates mutability
public class NutritionFacts {
    // Parameters initialized to default values (if any)
    private int servingSize = -1; // Required; no default value
    private int servings = -1; // Required; no default value
    private int calories = 0;
    private int fat = 0;
    private int sodium = 0;
    private int carbohydrate = 0;
    public NutritionFacts() { }
    // Setters
    public void setServingSize(int val) { servingSize = val; }
    public void setServings(int val) { servings = val; }
    public void setCalories(int val) { calories = val; }
    public void setFat(int val) { fat = val; }
    public void setSodium(int val) { sodium = val; }
    public void setCarbohydrate(int val) { carbohydrate = val; }
}

先调用一个无参构造器创建对象，然后调用setter方法设置每个必要的参数。

JavaBeans模式自身有很严重的缺点

1. 因为构造过程被分到了几个调用中，在构造的过程中JavaBeans可能处于不一致的状态。
2. JavaBeans模式阻止了把类做成不可变的可能，需要额外的处理保证线程的安全。

最佳替代：构建器（Builder模式）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

// Builder Pattern
public class NutritionFacts {
    private final int servingSize;
    private final int servings;
    private final int calories;
    private final int fat;
    private final int sodium;
    private final int carbohydrate;

    public static class Builder {
        // Required parameters
        private final int servingSize;
        private final int servings;
        // Optional parameters - initialized to default values
        private int calories = 0;
        private int fat = 0;
        private int sodium = 0;
        private int carbohydrate = 0;

        public Builder(int servingSize, int servings) {
            this.servingSize = servingSize;
            this.servings = servings;
        }

        public Builder calories(int val) {
            calories = val;
            return this;
        }

        public Builder fat(int val) {
            fat = val;
            return this;
        }

        public Builder sodium(int val) {
            sodium = val;
            return this;
        }

        public Builder carbohydrate(int val) {
            carbohydrate = val;
            return this;
        }

        public NutritionFacts build() {
            return new NutritionFacts(this);
        }
    }

    private NutritionFacts(Builder builder) {
        servingSize = builder.servingSize;
        servings = builder.servings;
        calories = builder.calories;
        fat = builder.fat;
        sodium = builder.sodium;
        carbohydrate = builder.carbohydrate;
    }
}

//----------------使用----------------------
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
.calories(100).sodium(35).carbohydrate(27).build();

不直接生成对象，而是让客户端利用所有必要的参数调动构造器（静态工厂），得到一个builder对象，然后在builder对象上调用类似setter的方法，最后调用无参的builder()方法生成不可变对象。builder类是它创建类的静态成员类。

优点：builder模式十分灵活，可以利用单个builder创建多个对象，可以自动填充某些属性。

缺点：性能开销

3. 用私有构造器或者枚举类型强化Singleton属性

Singleton单例是一个只实例化一次的类。

实现单例有两种常见的方法。两者都基于保持构造函数私有和导出公共静态成员以提供对唯一实例的访问。

1. 在第一种方法中，成员是一个 final 字段：

1
2
3
4
5
6

// Singleton with public final field
public class Elvis {
    public static final Elvis INSTANCE = new Elvis();
    private Elvis() { ... }
    public void leaveTheBuilding() { ... }
}

私有构造函数只调用一次，用于初始化 public static final 修饰的 Elvis 类型字段 INSTANCE。不使用 public 或 protected 的构造函数保证了「独一无二」的空间：一旦初始化了 Elvis 类，就只会存在一个 Elvis 实例，不多也不少。客户端所做的任何事情都不能改变这一点，但有一点需要注意：拥有特殊权限的客户端可以借助 AccessibleObject.setAccessible 方法利用反射调用私有构造函数。如果需要防范这种攻击，请修改构造函数，使其在请求创建第二个实例时抛出异常。

使用 AccessibleObject.setAccessible 方法调用私有构造函数示例：

1
2
3
4
5
6
7
8
9

Constructor<?>[] constructors = Elvis.class.getDeclaredConstructors();
AccessibleObject.setAccessible(constructors, true);

Arrays.stream(constructors).forEach(name -> {
    if (name.toString().contains("Elvis")) {
        Elvis instance = (Elvis) name.newInstance();
        instance.leaveTheBuilding();
    }
});

1. 在实现单例的第二种方法中，公共成员是一种静态工厂方法

1
2
3
4
5
6
7

// Singleton with static factory
public class Elvis {
    private static final Elvis INSTANCE = new Elvis();
    private Elvis() { ... }
    public static Elvis getInstance() { return INSTANCE; }
    public void leaveTheBuilding() { ... }
}

所有对 getInstance() 方法的调用都返回相同的对象引用，并且不会创建其他 Elvis 实例（与前面提到的警告相同）。

静态工厂方法的一个优点是，它可以在不更改 API 的情况下决定类是否是单例。工厂方法返回唯一的实例，但是可以对其进行修改，为调用它的每个线程返回一个单独的实例。第二个优点是，如果应用程序需要的话，可以编写泛型的单例工厂。使用静态工厂的最后一个优点是方法引用能够作为一个提供者，例如 Elvis::getInstance 是 Supplier<Elvis> 的提供者。除非能够与这些优点沾边，否则使用 public 字段的方式更可取。

但是要使单例类使用这两种方法中的任何一种实现可序列化，仅仅在其声明中添加实现 serializable 是不够的。

​ 要维护单例保证，应声明所有实例字段为 transient，并提供 readResolve 方法。否则，每次反序列化实例时，都会创建一个新实例，在我们的示例中，这会导致出现虚假的 Elvis。为了防止这种情况发生，将这个 readResolve 方法添加到 Elvis 类中：

1
2
3
4
5
6

// readResolve method to preserve singleton property
private Object readResolve() {
    // Return the one true Elvis and let the garbage collector
    // take care of the Elvis impersonator.
    return INSTANCE;
}

1. 从1.5开始，实现Singleton还可以编写一个包含单个元素的枚举类型

1
2
3
4
5

// Enum singleton - the preferred approach
public enum Elvis {
    INSTANCE;
    public void leaveTheBuilding() { ... }
}

这种方法类似于 public 字段方法，但是它更简洁，默认提供了序列化机制，提供了对多个实例化的严格保证，即使面对复杂的序列化或反射攻击也是如此。这种方法可能有点不自然，但是单元素枚举类型通常是实现单例的最佳方法。

注意：如果你的单例必须扩展一个超类而不是 Enum（尽管你可以声明一个 Enum 来实现接口），你就不能使用这种方法。

---

拓展：如何使用java枚举实现单例模式 - 问答 - 亿速云 (yisu.com)

4. 通过私有构造器强化不可实例化的能力

对于某些类比如java.lang.Math、java.util.Arrays等工具类，不希望被实例化，因为实例化没有任何意义。然而如果在缺少显示构造器的情况下，编译器会自动补全一个公有、无参的缺省（default）构造器。

同时，虽然将类声明成抽象类后就不能实例化，不能将不希望被实例化的类做成抽象类。因为该类可以被子类化，子类可以被实例化。这种做法会误导用户，以为这种类是专门为了继承而设计的。

我们可以将类声明一个私有的构造器，他就不能被实例化。

1
2
3
4
5
6
7

// Noninstantiable utility class
public class UtilityClass {
    // Suppress default constructor for noninstantiability
    private UtilityClass() {
        throw new AssertionError();
    } ... // Remainder omitted
}

因为显式构造函数是私有的，所以在类之外是不可访问的。AssertionError 不是严格要求的，但是它提供了保障，以防构造函数意外地被调用。它保证类在任何情况下都不会被实例化。这个习惯用法有点违反常规，因为构造函数是明确提供的，但不能调用它。因此，最好在代码中增加注释。

缺点：使一个类不能被子类化。

因为所有的构造器都必须显示或者隐式的调用超类（super）构造器，这种情况下，子类就没有可访问的超类构造器可调用。

5. 优先考虑依赖注入来引入资源

有许多类会依赖一个或多个底层的资源。不要用Singleton和静态工具类来实现依赖一个或多个底层资源的类；也不要直接用这个类来创建这些资源。应该将这些资源或者工厂传给构造器（或者静态工厂，或者构建器），通过他们来创建类。这种方式也叫作依赖注入。

以拼写检查程序为例，拼写检查依赖字典。常见的做法是将该类作为静态实用工具类

1
2
3
4
5
6
7

// Inappropriate use of static utility - inflexible & untestable!
public class SpellChecker {
    private static final Lexicon dictionary = ...;
    private SpellChecker() {} // Noninstantiable
    public static boolean isValid(String word) { ... }
    public static List<String> suggestions(String typo) { ... }
}

或者是其单例实现

1
2
3
4
5
6
7
8

// Inappropriate use of singleton - inflexible & untestable!
public class SpellChecker {
    private final Lexicon dictionary = ...;
    private SpellChecker(...) {}
    public static INSTANCE = new SpellChecker(...);
    public boolean isValid(String word) { ... }
    public List<String> suggestions(String typo) { ... }
}

缺点：他们都假设只使用了一个字典，但是在实际应用中，每种语言都有自己的字典，特殊的字典用于特殊的词汇表。

可以尝试让SpellChecker 支持多个字典：

首先，取消 dictionary 字段的 final 修饰，并在现有的拼写检查器中添加更改 dictionary 的方法。但是在并发环境中这种做法是笨拙的、容易出错的和不可行的。静态实用工具类和单例不适用于由底层资源参数化的类。

其次，需要的是能够支持类的多个实例（拼写检查器），每一个实例都是用客户端指定的资源（字典）。满足该需求最简单的模式就是，当创建一个新的实例时，就将该资源传到构造器中。这种形式也是依赖注入的一种。词典是拼写检查器的一个依赖，在创建拼写检查器的时候就将词典注入其中。

1
2
3
4
5
6
7
8
9

// Dependency injection provides flexibility and testability
public class SpellChecker {
    private final Lexicon dictionary;
    public SpellChecker(Lexicon dictionary) {
        this.dictionary = Objects.requireNonNull(dictionary);
    }
    public boolean isValid(String word) { ... }
    public List<String> suggestions(String typo) { ... }
}

依赖注入同样适用于构造器、静态工厂和构建器。这种模式另一种变体就是将资源工厂传递给构造器，工厂是可以被重复调用来创建类型实例的一个对象。这类工厂具体表现为工厂方法。

在Java 8中增加的接口Supplier<T>，最适合用于表示工厂。带有 Supplier<T> 的方法通常应该使用有界通配符类型来约束工厂的类型参数，以允许客户端传入创建指定类型的任何子类型的工厂。

比如，下面一个生产马赛克的方法，利用客户端提供的工厂来生产每一篇马赛克。

1

Mosaic create(Supplier<? extends Tile> tileFactory) { ... }

尽管依赖注入极大地提高了灵活性和可测试性，但它可能会使大型项目变得混乱，这些项目通常包含数千个依赖项。通过使用依赖注入框架（如 Dagger、Guice 或 Spring），几乎可以消除这种混乱。这些框架的使用超出了本书的范围，但是请注意，设计成手动依赖注入的API，一般都适用于这些框架。

6. 避免创建不必要的对象

一般来说，最好能重用对象而不是在每次需要的时候就创建一个功能相同的新对象。

1
2

String s = new String("bikini"); // DON'T DO THIS!‘
String s = "bikini";

第一条语句每次执行时都会创建一个新的 String 实例，而这些对象创建都不是必需的。String 构造函数的参数 ("bikini") 本身就是一个 String 实例，在功能上与构造函数创建的所有对象相同。如果这种用法发生在循环或频繁调用的方法中，创建大量 String 实例是不必要的。

第二条语句使用单个 String 实例，而不是每次执行时都创建一个新的实例。此外，可以保证在同一虚拟机中运行的其他代码都可以复用该对象，只要恰好包含相同的字符串字面量

对于同时提供静态工厂方法和构造器的不可变类，通常可以使用静态工厂方法而不是构造器，以避免创建不必要的对象

因为构造器每一次在被调用的时候都会创建一个新的对象，而静态工厂方法则从来不要求这样做。

有些对象创建的成本比其他对象要高得多，如果重复使用这类“昂贵的对象”，建议将它缓存下来重用。

比如，使用一个正则表达式：

1
2
3
4

// Performance can be greatly improved!
static boolean isRomanNumeral(String s) {
    return s.matches("^(?=.)M*(C[MD]|D?C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
}

这个问题在于String#matches方法。这个方法每次调用都会在内部为正则表达式创建一个Pattern实例（需要将正则表达式编译成一个有限状态机），但是只使用了一次就回收，成本很高。

为了提升性能，需要显示地将正则表达式编译成一个Pattern实例，让它成为类初始化的一部分，并缓存起来、

1
2
3
4
5
6
7
8
9

// Reusing expensive object for improved performance
public class RomanNumerals {
    private static final Pattern ROMAN = Pattern.compile("^(?=.)M*(C[MD]|D?C{0,3})" + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
    static boolean isRomanNumeral(String s) {
        return ROMAN.matcher(s).matches();
    }
}

即 变量.matches(常量) 变为 常量.matcher(变量).matches()

如果RomanNumerals类被初始化但是isRomanNumeral方法没有被使用过，则ROMAN对象理论上将不需要初始化。可以使用懒加载ROMAN对象。但是，不建议懒加载ROMAN，会使方法实现更加复杂。

类加载通常指的是类的生命周期中加载、连接、初始化三个阶段。当方法没有在类加载过程中被使用时，可以不初始化与之相关的字段

当一个对象是不可变的，很明显，它可以安全地复用，但在其他情况下，它远不那么明显，甚至违反直觉。考虑适配器的情况，也称为视图。适配器是委托给支持对象的对象，提供了一个替代接口。因为适配器的状态不超过其支持对象的状态，所以不需要为给定对象创建一个给定适配器的多个实例。

例如，Map 接口的 keySet 方法返回 Map 对象的 Set 视图，其中包含 Map 中的所有键。天真的是，对 keySet 的每次调用都必须创建一个新的 Set 实例，但是对给定 Map 对象上的 keySet 的每次调用都可能返回相同的 Set 实例。虽然返回的 Set 实例通常是可变的，但所有返回的对象在功能上都是相同的：当返回的对象之一发生更改时，所有其他对象也会发生更改，因为它们都由相同的 Map 实例支持。虽然创建 keySet 视图对象的多个实例基本上是无害的，但这是不必要的，也没有好处。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// keySet源码

/**
  * 获取HashMap的键的集合，以Set<K>保存
  * @return 返回key的集合
  */
public Set<K> keySet() {
/*
  说明：
1.可以看到其实该方法中，并没有将HashMap中的键添加到Set集合中，那么是如何实现的呢？
2.但实际上，我们访问Set集合，根本就无法通过索引，而是需要通过迭代器Iterator才能访问到元素，foreach本质上也是迭代器
3.这里的 ks 就仅仅只是一个Set引用，指向HashMap内部类KeySet的一个实例，重点在于该实例拥有自己的迭代器，当我们在使用增强for循环时才会调用该迭代器，也才会输出我们想要的东西
*/
    Set<K> ks = keySet;
    if (ks == null) {
        ks = new KeySet();
        keySet = ks;
    }
    return ks;
}

来源：https://blog.csdn.net/cnds123321/article/details/113791846

另一种创建不必要对象的方法是自动装箱，它允许程序员混合基本类型和包装类型，根据需要自动装箱和拆箱。自动装箱模糊了基本类型和包装类型之间的区别， 两者有细微的语义差别和不明显的性能差别。考虑下面的方法，它计算所有正整数的和。为了做到这一点，程序必须使用 long，因为 int 值不够大，不足以容纳所有正整数值的和：

1
2
3
4
5
6
7

// Hideously slow! Can you spot the object creation?
private static long sum() {
    Long sum = 0L;
    for (long i = 0; i <= Integer.MAX_VALUE; i++)
        sum += i;
    return sum;
}

教训很清楚：基本类型优于包装类，还应提防意外的自动装箱。

本条目不应该被曲解为是在暗示创建对象是成本昂贵的，应该避免。相反，创建和回收这些小对象的构造函数成本是很低廉的，尤其是在现代 JVM 实现上。创建额外的对象来增强程序的清晰性、简单性或功能通常是件好事。

相反，通过维护自己的对象池来避免创建对象不是一个好主意，除非池中的对象非常重量级。证明对象池是合理的对象的典型例子是数据库连接。建立连接的成本非常高，因此复用这些对象是有意义的。然而，一般来说，维护自己的对象池会使代码混乱，增加内存占用，并损害性能。现代 JVM 实现具有高度优化的垃圾收集器，在轻量级对象上很容易胜过这样的对象池。

当前项的描述是：「在应该复用现有对象时不要创建新对象」，而 Item 50 的描述则是：「在应该创建新对象时不要复用现有对象」。请注意，当需要进行防御性复制时，复用对象所受到的惩罚远远大于不必要地创建重复对象所受到的惩罚。在需要时不制作防御性副本可能导致潜在的 bug 和安全漏洞；而不必要地创建对象只会影响样式和性能。

7. 消除过期的对象引用

即使Java有内存管理机制，对于开发者来说仍需要考虑内存管理的问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

import java.util.Arrays;
import java.util.EmptyStackException;

// Can you spot the "memory leak"?
public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(Object e) {
        ensureCapacity();
        elements[size++] = e;
    }

    public Object pop() {
        if (size == 0)
            throw new EmptyStackException();
        return elements[--size];
    }

    /**
     * Ensure space for at least one more element, roughly
     * doubling the capacity each time the array needs to grow.
     */
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

上面这段代码没有明显的错误。但是程序中隐藏着一个问题，可能会存在“内存泄露”。如果一个栈先是增长（push），然后收缩（pop），被栈弹出的对象不会被当做垃圾回收。（因为这个弹出只是逻辑上的弹出，弹出的对象仍然在数组中）。所以存在内存泄露的风险。这种引用也被称为过期引用

过期引用：本文的过期引用指逻辑上应该被清空，但是物理上还存在的引用。

这类问题的修复很简单，一旦对象引用过期，只需要手动清空这些引用即可。

1
2
3
4
5
6
7

public Object pop() {
    if (size == 0)
        throw new EmptyStackException();
    Object result = elements[--size];
    elements[size] = null; // Eliminate obsolete reference
    return result;
}

清空过期引用有另一个好处：如果这些过期引用又被错误的使用，程序就会立刻抛出NullPointerException异常，而不是悄悄的错误运行下去。

但是也没有必要过分小心：对于每一个对象引用，一旦程序不再使用，就把它清空。因为这样会把代码弄得很乱，后期也不容易维护。清空对象引用应该是一种例外，而不是一种规范的行为。消除过期引用最好的方法就是让包含该引用的变量结束其生命周期。

但为何上述Stack存在内存泄露的风险？

简单地说，它管理自己的内存。存储池包含元素数组的元素（element, 对象引用单元，而不是对象本身）。数组的活动部分（size）中的元素被分配，而数组其余部分中的元素是空闲的。垃圾收集器没有办法知道这一点；对于垃圾收集器，元素数组中的所有对象引用都同样有效。只有程序员知道数组的非活动部分不重要。只要数组元素成为非活动部分的一部分，程序员就可以通过手动清空数组元素，有效地将这个事实传递给垃圾收集器。

注意事项：

所以，只要类是自己管理内存，程序员就应该警惕内存泄露问题。一旦元素被释放掉，则该元素中包含的任何对象引用都应该被清空。

同时，也要注意缓存，因为内存泄露的另一个常见来源是缓存。一旦将对象引用放入缓存中，就很容易忘记它就在那里，并且后续不在使用的时候仍在留在缓冲中一段时间。

避免方式：

1. 可以在缓存中使用弱引用，保证缓存的自动清除。当缓存对象只有缓存的弱引用时，就会在下一个垃圾回收时回收。

2. 增加一个后台线程（比如ScheduledThreadPoolExecutor），或者在缓存添加新条目的时候顺带清除掉没用的对象。

还有，缓存泄露的第三个常见来源是监听器和其他回调。比如，实现了一个API，客户端在这个API中注册了回调，但是没有显示的取消注册，那么除非采取某些动作，否则他们就会不断的堆积起来。

避免方式：

确保回调立即被当做垃圾回收的最佳方式就是只保存它们的弱引用，比如只将它们保存成WeakHashMap中的键。

最后，可以考虑借助Heap剖析工具（Heap profiler）发现内存泄露问题。

8. 避免使用终结方法和清除方法

本小节内所表述的使用终结方法、清除方法是指像普通方法一样使用，不作为安全网时使用。

终结方法通常是不可预测的，一般情况下不建议使用。及时在Java 9中用清除方法代替了终结方法，但是仍是不可预测、运行缓慢的。

类的终结方法、清除方法的缺点：

1. 不能保证会被及时执行。从一个对象变得不可到达开始，到他的终结方法被执行，所花费的这段时间是任意长的。注重时间的任务不应该由终结方法或者清除方法来完成。比如文件类型。

   Java语言规范不仅不保证终结方法或者清除方法会被及时的执行，甚至根本就不保证他们会被执行。有一种可能：当程序终止的时候，某些对象的终结方法还没有被执行。永远不应该依赖终结方法或者清除方法来更新重要的持久状态。

   即使Java底层有System.gc和System.runFinalization这两个方法，这也只是增加了终结方法和清除方法被执行的机会，并不能保证终结方法或者清除方法一定被执行。

2. 使用终结方法，无法捕获该方法中的异常，甚至连警告都不会打印出来。（清除方法没有这个问题：因为使用清除方法的一个类库在控制它的线程）。

3. 使用终结方法和清除方法会有非常严重的性能损失。（但是如果把终结方法、清除方法作为安全网，则效率不会性能很多）

4. 终结方法有一个严重的安全问题，为终结方法攻击提供了可能。即如果对象在执行构造方法的时候抛出异常，终结方法也会运行，即使这个类的构造方法没有执行完。总之：从构造器抛出的异常，应该足以防止对象继续存在；但有了终结方法，这点就做不到了。

如果类对象中封装了资源（比如文件或者线程），确实终止。只需让类实现AutoCloseable，并重写close方法，客户端在实例不需要的时候调用close方法即可。

值得提及的一个细节是，该实例必须记录下自己是否已经被关闭了：close方法必须在一个私有域中记录下“该对象已经不再有效”。 如果这些方法是在对象已经终止之后被调用，其他的方法就必须检查这个域，并抛出 IllegalStateException 异常。

类的终结方法、清除方法的优点：

1. 当资源的所有者忘记调用close方法时，终结方法或者清除方法可以充当“安全网”。虽然不能保证方法被及时的运行。
2. 方便关闭对象的本地对等体。本地对等体就是一个本地（非Java的）对象，是普通对象（Java对等体）通过本地方法委托给一个本地对象。因为本地对象不会被Java的垃圾回收器回收，所以可以在Java对等体被回收的时候，使用终结方法、清除方法关闭本地对等体。

清除方法的使用有一定的技巧，下面以简单的Room类为例，假设房间在回收之前必须被清除。Room类实现了AutoCloseable，并利用清除方法自动清除。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

import sun.misc.Cleaner;

// An autocloseable class using a cleaner as a safety net
public class Room implements AutoCloseable {
    private static final Cleaner cleaner = Cleaner.create();

    // Resource that requires cleaning. Must not refer to Room!
    private static class State implements Runnable {
        int numJunkPiles; // Number of junk piles in this room

        State(int numJunkPiles) {
            this.numJunkPiles = numJunkPiles;
        }

        // Invoked by close method or cleaner
        @Override
        public void run() {
            System.out.println("Cleaning room");
            numJunkPiles = 0;
        }
    }

    // The state of this room, shared with our cleanable
    private final State state;
    // Our cleanable. Cleans the room when it’s eligible for gc
    private final Cleaner.Cleanable cleanable;

    public Room(int numJunkPiles) {
        state = new State(numJunkPiles);
        cleanable = cleaner.register(this, state);
    }

    @Override
    public void close() {
        cleanable.clean();
    }
}

内嵌的静态类State保存清除方法清除房间所需的资源；numJunkPiles域，表示房间的杂乱度。State实现了Runnable接口，他的run方法最多被Cleanable调用一次。有两种情况会触发run方法的调用：1. 调用Room的close方法，本质是调用cleanable.clean()。2. 如果Room实例应该被垃圾回收时，客户端没有调用close方法，清除方法就会调用State的run方法。

State实例没有引用它的Room实例。 如果它引用了就会造成循环，阻止Room实例被垃圾回收（以及防止被自动清除）。因此State必须是一个静态的嵌套类，因为非静态的嵌套类包含了对其外围实例的引用。同样地，也不建议使用lambda, 因为它们很容易捕捉到对外围对象的引用。

就像之前说的，Room类的清除器只是用作安全网。如果客户端将所有Room实例包围在带有资源的try块中，则永远不需要自动清理。

1
2
3
4
5
6
7

public class Adult {
    public static void main(String[] args) {
        try (Room myRoom = new Room(7)) {
            System.out.println("Goodbye");
        }
    }
}

但如果是下面这种场景，则不会打印出”Cleaning room”。

1
2
3
4
5
6

public class Teenager {
    public static void main(String[] args) {
        new Room(99);
        System.out.println("Peace out");
    }
}

因为Cleaner规范：清除方法在System.exit期间的行为和实现有关，但是不确保清除方法是否会被调用。

在sout之前，添加System.gc()，就可以让其在退出之前打印出Cleaning room。

总而言之，除非是作为安全网，或者是为了终止非关键的本地资源，否则请不要使用清除方法，对于在Java 9之前的发行版本，则尽量不要使用终结方法。若使用了终结方法或者清除方法，则要注意它的不确定性和性能后果。

9. try-with-resource优先于try-finally

Java库包含许多必须通过调用close方法手动关闭的资源。常见的有InputStream、OutputStream 和 java.sql.Connection。客户端经常会忽略资源的关闭，而造成严重的性能后果。虽然许多资源用终结方法作为安全网，但是这种方法也不是很理想。

根据经验，try-finally 语句是确保正确关闭资源的最佳方法，即使在出现异常或返回时也是如此：

1
2
3
4
5
6
7
8
9

// try-finally - No longer the best way to close resources!
static String firstLineOfFile(String path) throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        br.close();
    }
}

这可能看起来好像也不坏，但添加第二个资源时，情况会变得更糟：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// try-finally is ugly when used with more than one resource!
static void copy(String src, String dst) throws IOException {
    InputStream in = new FileInputStream(src);
    try {
        OutputStream out = new FileOutputStream(dst);
        try {
            byte[] buf = new byte[BUFFER_SIZE];
            int n;
            while ((n = in.read(buf)) >= 0)
                out.write(buf, 0, n);
        } finally {
            out.close();
            }
        }
    finally {
        in.close();
    }
}

即使try-finally语句正确地关闭了资源，但是也存在一些不足：

​ 以第一个firstLineOfFile为例，如果运行时物理设备异常，则调用readLine方法时就会抛出异常，但是由于同样的原因，close方法也会异常。这种场景下，第二个异常完全抹除了第一个异常，在异常堆栈里找不到第一个异常。这时候有可能会使调试变得非常复杂。

当 Java 7 引入 try-with-resources 语句时，所有这些问题都一次性解决了。要使用这个结构，资源必须实现 AutoCloseable 接口，它包含了单个返回void的 close 方法组成。Java 库和第三方库中的许多类和接口现在都实现或扩展了 AutoCloseable。如果你编写的类存在必须关闭的资源，那么也应该实现 AutoCloseable。

下面是使用 try-with-resources 的第一个示例：

1
2
3
4
5
6

// try-with-resources - the the best way to close resources!
static String firstLineOfFile(String path) throws IOException {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

下面是使用 try-with-resources 的第二个示例：

1
2
3
4
5
6
7
8
9

// try-with-resources on multiple resources - short and sweet
static void copy(String src, String dst) throws IOException {
    try (InputStream in = new FileInputStream(src);OutputStream out = new FileOutputStream(dst)) {
        byte[] buf = new byte[BUFFER_SIZE];
        int n;
        while ((n = in.read(buf)) >= 0)
            out.write(buf, 0, n);
    }
}

和使用 try-finally 的最开始的两个代码相比，try-with-resources 为开发者提供了更好的诊断方式。如果使用 try-with-resources ，这时候运行 firstLineOfFile 方法，如果异常是由 readLine 调用和不可见的 close 抛出的，第二个异常就会被禁止，第一个异常就会被保留（如果有多个异常，也只会保留第一个）。这些被禁止的异常并不是被简单的抛弃，而是被打印在堆栈轨迹中，并注明是被禁止的异常。通过编程调用getSuppressed方法还可以访问到它们。【getSuppressed方法也已经添加在java 7的Throwable中了】。

try-with-resources 中也可以使用 catch 子句，比如：

1
2
3
4
5
6
7
8

// try-with-resources with a catch clause
static String firstLineOfFile(String path, String defaultVal) {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
        return br.readLine();
    } catch (IOException e) {
        return defaultVal;
    }
}