《DDD开篇总结》的前三篇已经阐述了几个内容

1. DDD是什么
2. 复杂系统的特征
3. DDD如何应对复杂系统
4. 模型概念
5. 软件开发流程

但一般DDD资料中都会分为两部分讲述：战略和战术，所以按这两种分类，重新归纳整合一下

道

在讨论战略和战术前，先表述一下“道”

DDD是一种软件开发的方法论，任何方法论，都必须落实到“减少代码复杂度”

那么“道”是什么呢？

一直认为DDD的战略就是道，结果搞错了

软件开发的终极“道”就是“高内聚、低耦合”，它是任何有价值思想和方法的具象

如何才能达到这个终极道呢？

• 1. DRY
• 2. 分离关注点
     • 2.1. 业务和技术分离
     • 2.2. 业务和部署分离
     • 2.3. 变与不变分离
• 3. 缩小依赖范围
• 4. 向稳定方向依赖

战略

DDD战略主要包含统一语言和限界上下文

统一语言

在以往OO开发过程中，会经过OOA，再到OOD，复杂系统中，没有人能全方位了解系统并实现系统，术业有专工，专业人士干伟业事，这是正确的

但分工后，团队合作时沟通至关重要，，在整个系统开发过程中，是有一根主线的，那就是业务知识，业务知识在系统落地前经过层层传递，走样变形是常有的事，从开发人员经过多少次的返工情况就很清楚

如果解决这个问题呢？DDD引入了统一语言，把业务名词含义事先确定好，减少不必要的翻译过程，车同轨，书同文，行同伦

这也消除了业务与技术之间的重复，共同使用业务原语对话

代码就是文档，代码就是领域知识

1
2

userService.love(Jack, Rose) => Jack.love(Rose)
companyService.hire(company,employee) => Company.hire(employee)

界限上下文

界限上下文囊括了实现道的方方面面，如分离关注点，每个上下文围绕一个关注点，通过整洁架构让各层向稳定方向依赖，合理的划分界限，使各个上下文之间减小依赖

说白了界限上下文就是把一个大系统分而治之

界限上下文算是DDD中的核心知识点，但常被技术人员忽视，对于实用主义的程序员来讲，战术常常更吸引人，其实大到微服务，小到实体类，背后都渗透着上下文的概念

引入限界上下文的目的，不在于如何划分边界，而在于如何控制边界

Alberto Brandolini认为bounded context are a mean of safety（限界上下文意味着安全），safety的意思是being in control and no surprise，对限界上下文是可控制的，就意味着你的系统架构与组织结构都是可控的

显然，限界上下文并不是像大多数程序员理解的那样，是模块、服务、组件或子系统，而是你对领域模型、团队合作以及技术风险的控制

限界上下文是“分而治之”架构原则的体现，我们引入它的目的其实为了控制（应对）软件的复杂度，它并非某种固定的设计单元，我们不能说它就是模块、服务或组件，而是通过它来帮助我们做出高内聚低耦合的设计。只要遵循了这个设计，则限界上下文就可能成为模块、服务或组件。所以，文章《Bounded Contexts as a Strategic Pattern Beyond DDD》才会写到：“限界上下文体现的是高层的抽象机制，它并非编程语言或框架的产出工件，而是体现了人们对领域思考的本质。”

战术

对于开发人员而，战术是最实用的，比如聚合、实体、值对象、工厂、仓储、领域事件等等，
使用这些战术组件建模工具，DDD满足了软件真正的技术需求。这些战术设计工具使开发人员能够按照领域专家的思维开发软件

战略部分讲了，界限上下文的思想是核心，在战术组件中都有体现，比如实体，实体就是一个最小上下文，聚合就是相对实体大一点的上下文

但残酷的现实是，花费了大量的精力来学习这些DDD战术组件，却在实现项目中却用不上，为什么呢？因为事务脚本思维太深，分层也大多是从技术角度出发，没有抽象出领域模型，也就是没有OO抽象，没有一个完整的对象，实体都没有，像工厂，值对象也就成了水中花

这也是我们虽然常重构代码，也不过是大类变小类，大函数拆分成小函数，符合一下代码规范，但对整个项目而言，其实没有实质性改进

如何能有实质性改进，对于复杂系统如何运用上这些战术组件呢？

此时，结构性思维发挥作用了

第一步：过程分解，把一个复杂的系统按流程拆解成各个阶段和步骤，这也是事务脚本的强项

第二步：对象建模，过程性拆解虽然可以降低了开发难度，但领域知识被割裂，代码的业务语义也不明确，在这方面OO是强项，提升代码复用性和内聚性

结合这两步，自上而下的结构化分解+自下而上的面向对象建模，过程化分析更好地清理了模型之间的关系，而对象模型提升代码复用性和业务语义表达能力

总结

DDD是一套很好的方法论，有时我们常在理论纯洁性与实战性之间徘徊。这也许是初级阶段常有的纠结点

DDD有适用场景，事务脚本有存在的优势

不能因为现在人们开口闭口都是DDD，就硬要开展DDD

DDD难以落地除了本身带来了很多概念，还需要团队整体素质

软件开发没有银弹，不能偏执于一种理论，实际开发是场硬仗，像混合格斗一样，不在于一招一式是哪门哪派，制敌才是终极目标，所以需要根据自身情况进行裁剪，灵活运用

之前写了两篇《DDD开篇》与《DDD应对复杂》，是时候总结一下了

对于DDD的启蒙，不管是国内还是国外思维逻辑都是一样的。或者说如果你想写本关于DDD的书，大纲似乎是一样的

首先DDD是什么？给出定义，定义有些抽象，难以一次性接受，那就通过以往问题引出DDD，这时模型、复杂度、开发流程都是自然附带出的概念，再后面就是DDD的知识结构是什么，最后就是讲解一个实例，也有些会把实例穿插到各个篇章中

在DDD这个系列中，我也打算是这种思路，很平易近人

经过了之前两篇，对于第一部分的DDD是什么？为什么需要DDD基本都问答清楚了。

DDD是什么

DDD根本上是一种软件开发的建模方法论，其中使用了面向对象分析思想，并不是独立于外全新的体系

模型是对现实世界的抽象，那建模是对现实世界的抽象过程，但模型毕竟是模型，不能代替现实，就像类比不能代替问题本身一样。建模过程与建模者的观察视角和对问题的认知有直接关系,所以我们要带着审视的眼光看待模型

软件开发的最大问题之一便是业务人员和技术人员需求某种翻译才能交流，那么模型的质量就取决于翻译的还原度

建模不仅要还原实现世界，更要把重要的东西进行显示化。是一个软件之所以是这个软件的核心

建模可以通过建模=构造块+语法范式表达，各类语言都可以通过这种范式表达出来

(1) 自然语言建模

构造块：常用的那几千个汉字（或者英语的10万单词）

语法规则：主谓宾定状补

(2)计算机语言建模

构造块：加/减/乘/除，if-else, for, while..

语法规则：程序员最熟悉，此处就不说了

(3)过程建模

构造块：函数

语法规则：整个系统描述成一个个过程，每个过程通过函数的层层调用组成

(4)对象建模

构造块：对象

语法规则: 整个系统描述成对象与对象之间的关系

(5) DDD领域建模

构造块：实体/值对象/领域服务/领域事件/聚合根/工厂/仓库/限界上下文

语法规则：就是“构造块”之间的联系（不是很明显，这个需要深入研究。也正是DDD难掌握的地方）

为什么需要DDD

之前介绍过软件复杂度以及应对复杂度之道，DDD是其中一种术

1. 使领域专家和开发者在一起工作，这样开发出来的软件能够准确地传送业务规则
2. “准确传达业务规则”意思是说此时的软件就像如果领域专家是编码人员时所开发出来的一样
3. 帮助业务人员自我提高。没有任何一个领域专家或管理者敢说他对业务已经了如指掌，业务知识需要长期学习过程，在
   DDD中，每个人都在学习，同时每个人又是知识贡献者
4. 关键在于对知识的集中，因为这样可以确保软件知识并不只是掌握在少数人手中
5. 在领域专家、开发者和软件本身之间不存在“翻译”，意思是当大家都使用相同的语言进行交流时，每个人都能听懂他人所说
6. 设计就是代码，代码就是设计。设计是关于软件如何工作的，最好的编码设计来自多次试验，这得益于敏捷的发现过程
7. DDD同时提供了战略设计和战术设计两种方式,战略设计帮助我们理解哪些投入是最重要的，哪些既有软件资产是可以重新拿来使用的，哪些人应该被加到团队中？战术设计帮助我们创建DDD模型中各个部件

上面的比较学术，简单讲：理解DDD的本质是统一语言、边界划分和面向对象分析的方法

1. 统一语言，主要思想是让应用能和业务相匹配，这是通过在业务与代码中的技术之间采用共同的语言达成的。也就是设计及代码，代码及设计
2. 面向对象，DDD核心是领域模型，先找到业务中的领域模型，以领域模型为中心，驱动项目开发，指引我们如何实现面向服务架构或业务驱动架构。领域模型设计精髓在于面向对象分析，对事物的抽象能力，一个领域驱动架构师必然是一个面向对象分析大师
3. 业务语义显示化，统一语言也好，面向对象也好，最终目标都是为代码可读性和可维护性服务，统一语言使得核心领域概念无损地在代码中呈现，从而提升代码的可理解性
4. 分离业务逻辑和技术细节，让两个维度的复杂度被解开和分治，比如整洁架构

对于最终目标来讲，在软件项目中，任何方法论如果最终不能落在“减少代码复杂度”，都是有待商榷的

DDD挑战

DDD在实践中有很高的门槛

1. 持续地将领域专家引入项目
2. 为创建通用语言腾出时间和精力
3. 改变开发者对领域的思考方式

最大挑战之一便是：需要花费大量的时间和精力来思考业务领域，研究概念和术语，并且和领域专家交流，以发现、捕捉和改进通用语言

在开发过程中，最大的鸿沟之一便是在于领域专家和开发者之间，通常领域专家关注放在交付业务价值上，而开发者则将注意力放在技术实现上。并不是说开发者动机是错误的，面是说开发者的眼光被自然而然地吸引到实现层面。即使让领域专家与开发者一同工作也只是表面协作，这样在开发的软件中产生了一种映射：业务人员所想的映射到开发者所理解的，软件便不能完全反映领域专家的思维模型，随着时间推移，这种鸿沟将增加软件开发成本

DDD将领域专家与开发人员聚焦在一起，这样所开发的软件能够反映出领域专家的思维模型，这并不意味着我们将精力都花在对“真实世界”的建模上，而是交付最具业务价值的软件，在实用和理想之间存在冲突时，根据它们的互异程序，在DDD中选择实用性

领域专家与开发人员一起创建一套适用于领域建模的通用语言。通用语言必须在全队范围之内达成一致；所有成员都使用通用语言进行交流，通用语言是对软件模型的直接反映

作为开发者，我们都是技术思想者，技术实现对于我们来说并不是什么难事。并不是说技术地思考不好，只是说有时少从技术层面去思考会更好。这么多年来，我们习惯了单从技术层面完成软件开发，那现在是时候考虑一种新的思考方式了。为你的业务领域开发一门通用语言便是一个好的出发点

技术负债

程序员工作时间大部分在新增新功能，996式加班大多为了赶工上线，而对赶工出来的软件质量是在打个问题，而技术负债在软件质量领域是一个很能重要概念，对于软件工程来讲，这真是个特别的东西

Martin Fowler定义技术负债就是增加新功能所需要的额外成本

软件质量不同于其他商品质量。购买一个商品，在使用过程中会直接发现该商品质量问题，而软件质量不是直接被软件系统的使用者所感知的，也就是说客户如果同时使用两种质量不同的系统，用户是无法发现两者的区别，不过随着时间推移，自己的产品交付过程越来越长了

软件质量问题不是直接面向用户，而是面向软件的开发团队。因为软件质量差，新程序员很难快速上手，无法形成生产力；修改别人的代码时可能一走在不得要领；bug丛生，修复一个可能使得系统崩溃，一个都不修复系统反而正常工作；修复bug时牵一动百，修改一处却引起其他连锁故障反应。。。，这些都是软件质量低下的外在表现

正是由于软件质量不是最终用户所能感知的，导致行业内对软件质量没有过多重视–客户都没有提出改进要求，那么一切为客户服务的软件公司自然没有动力去提升软件质量，而且行业内对软件质量存在认知误区：便宜确实没好货，但是质量高必然导致成本 上升，而客户又不会察觉质量好坏，那么产品如何卖出好价格

软件并不是质量越高，成本就越高。这似乎违反常识，背后其实也与技术负债有关。如果将技术负债看成是一种前进中的累赘，累赘遍布于代码各处，那么提高软件质量就是通过良好设计或重构来减轻这种累赘，从而能轻装上阵，新增功能就能更加快捷，交付效率也会大大提升。

降低技术负债意味着软件质量提高，软件质量越高，修改拓展起来就越方便。

如何降低技术负债？这存在一个适度问题，代码越多，复杂性越高，技术负债肯定越高，那么就需要惜墨如金。有时为了写正确可运行的简洁代码，可能要删除数十倍的代码，但也不是代码越少越好。有的代码只是考虑功能实现，没有考虑到功能的对接或扩展，那么当需要对功能实现扩展时，就发现难以下手，甚至需要采取黑客破解方式强行入侵系统，这此都是原来代码过于简单僵化的表现

适度是在过度和不足中探索平衡的结果。代码适度的一个衡量标准是单一职责原则，即每个函数或类只能有一个职责。

面向对象编程中还有另一个原则：DRY原则。对这个原则的共同理解是代码不应该重复，如果两段代码表示的是同一个职责，那么合并它们。但这种抽象合并导致共享内核或共享库，最张造成代码各处对共享库或内核的依赖，这就很自然地引入了不必要的、偶然的复杂性–一旦共享库发生修改，牵一动百的事情就可能发生。很多时候重复的代码可能会带来相当大的优势，重复能拖延决策，这是软件开发的黄金。这样，延迟到适当时机从多个专业化角度重构，这比从单个方法层面进行抽象的重构要容易数倍。

复杂

Eric Evans所著副标题–Tackling Complexity in the Heart of Software，对于简单系统其实没有必要使用DDD，只有在复杂系统中，才能体现DDD的价值

那么何为“复杂”，或者说为什么软件是复杂的呢？

即使是研究复杂系统的专家，如《复杂》一书的作者 Melanie Mitchell，都认为复杂没有一个明确得到公认的定义。不过，Melanie Mitchell 在接受 Ubiquity 杂志专访时，还是“勉为其难”地给出了一个通俗的复杂系统定义：由大量相互作用的部分组成的系统，与整个系统比起来，这些组成部分相对简单，没有中央控制，组成部分之间也没有全局性的通讯，并且组成部分的相互作用导致了复杂行为。

这个定义同样可以表达软件复杂度的特征。定义中的组成部分对于软件系统来说，就是我所谓的“设计单元”，基于粒度的不同可以是函数、对象、模块、组件和服务。这些设计单元相对简单，然而彼此之间的相互作用却导致了软件系统的复杂行为。

《管理3.0：培养和提升敏捷领导力》中从两个维度分析复杂：行为（预测能力）和结构（理解能力），分别举了实际生活中简单的例子

理解力维度分为 Simple 与 Comlicated 两个层次，预测能力维度则分为 Ordered、Complex 与 Chaotic 三个层次

在英文中，表示复杂的有Complicated和Complex

Simple = easily knowable.

Complicated = not simple, but still knowable.

Complex = not fully knowable, but reasonably predictable.

Chaotic = neither knowable nor predictable.

参考复杂的含义，Complicated 与 Simple（简单）相对，意指非常难以理解，而 Complex 则介于 Ordered（有序的）与 Chaotic（混沌的）之间，认为在某种程度上可以预测，但会有很多出乎意料的事情发生

针对复杂的定义，分析角度以及应对的方法，绘制一张表格:

根据上面的总结，想起《架构与架构师》中提到的架构师需要面对应用程序的两个层面需求：功能需求与非功能需求，功能性需求越多越大那对应的软件规模增长越快，可变性越大；非功能需求就要考虑质量属性，也就是整体结构要清晰，明确的规范约束，易于理解好维护。而这两个层面需求正好又对应着业务复杂度与技术复杂度

技术复杂度与业务复杂度并非完全独立，二者混合在一起产生的化合作用更让系统的复杂度变得不可预期，难以掌控。同时，技术的变化维度与业务的变化维度并不相同，产生变化的原因也不一致，倘若未能很好地界定二者之间的关系，系统架构缺乏清晰边界，会变得难以梳理。复杂度一旦增加，团队规模也将随之扩大，再揉以严峻的交付周期、人员流动等诸多因素，就好似将各种不稳定的易燃易爆气体混合在一个不可逃逸的密闭容器中一般，随时都可能爆炸：

DDD应对

这让我回想起了“结构化思维”，逻辑+套路

逻辑是一种能力，而套路是方法论，是经验。逻辑是道，方法论是术；逻辑可以学习很多思维模型理论，但套路有路径依赖，这也是去大厂的好处，可以接触到各种大牛，直接获取他们的经验和方法

DDD是如何应对这些复杂性的呢？

1. 限界上下文分而治之，边界划分后，各子域相对整体规模就小了
2. 结构方面通过技术角度：分层架构、六边形架构…分离技术实现与业务逻辑
3. 变化，不再过程式编程，加强抽象领域模型，通过过程分解+对象模型，拆解并业务显示化，达到更好的复用性和易理解性

banq提出类似总结解决复杂性两种方法：拆解成松耦合的组件+使用容易让人明白的套路表达出来

拆解也就是引入了“领域或子域”以及“有界上下文”划分边界；再引入各种模式名词，比如聚合、实体、值对象、工厂、仓储、领域事件，让知晓这些模式的人能够一下子定位到功能对应实现的组件，随着人们逐步了解，对于理解DDD系统来说，就不再是复杂的

开发流程

我们在开发、运营、维护软件的过程中很多技术、做法、习惯和思想。软件工程把这些相关的技术和过程统一到一个体系中，叫“软件开发流程”，软件开发流程的目的是为了提高软件开发、运营和维护的效率，以及提升用户满意度、软件的可靠性和可维护性

发展了很多的流程，这儿复习一下最资深的瀑布模型

瀑布模型

瀑布模型(Waterfall Model)1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型

当软件行业还在年幼时期，它从别的成熟行业(硬件设计，建筑工程)借用了不少经验和模型。在那些“硬”的行业中，产品大多数遵循[分析->设计->实现(制造)->销售->维护]这个流程

软件系统很难做到像建筑行业一样，程序员只要根据图样一步步实施就能完成项目。没人可以完整设计出一个大型项目的图样，这是瀑布软件工程方法的致命问题

比如A拥有一家跑车公司，可以给客户自定义生产跑车。有一天一土豪来到A的公司，跟A商谈了一个跑车项目，他们谈好了车型，材料，马力等等细节。之后，A带着团队做了6个月，做成了这架跑车，交给了土豪。可是土豪开了一天之后回来要求重做，原因是当讨论方案的时候，双方都忘记给跑车安尾灯了！

但是给跑车安装尾灯，需要重新设计车尾部，加上倒车灯，把车底拆开，安装线路，修改传动装置把倒车档和倒车灯联系起来

软件多变，而且很长周期后才让用户看到最终产品，反反复复

瀑布模型只能在产品的定义非常稳定；产品模块之间的接口、输入和输出能很好地用形式化的方法定义和验证

统一语言

软件行业相对其它传统行业有独特的难，同为构建，建筑工程在施工队进场开始构造之前，各种工程图样和材料都已经非常精确地准备到位，但在软件中没有足够时间收集所有需地，即使收集了，需求也不是从创建软件角度去描述

软件项目团队，从产品 到 开发，再到测试，应了那句不怕神一样的对手，就怕猪一样的队友，层层兜底，产品考虑不到的，开发帮兜底，开发不给力时，靠测试兜底，测试不走心的，那只能客户买单，名为兜底大队

项目开始，产品没有足够时间收集需求，但快速行动的重要性扎根程序员内心，没有足够信息来构建，可项目有交付期限，程序员只能进行创造性假设，填补产品经理留下的空白，只是为了保持项目不断推进。但产品经理或者客户经常改变主意，这意味着程序员对留白处的创建性假设经常夭折

项目实践需求与程序员的理解之间存在客观落差，但程序员负责最终完成项目，如果这种落差没有被注意或发现，就只能由程序员自己创造。这种创造是在没有指导或指示的情况下进行，当项目展示给客户时，客户才发现不是自己想要的，双方就容易争执

更多时候，程序员之所以在项目开始迟迟不亡友，是因为他们希望有人告诉该怎么做，但这种情况一般不会发生，这时就发挥自己的创造力，但这个创造有时会使项目偏离正确方向。如何发挥程序员创造力，同时又能保持项目的方向不被程序员带偏呢？

解决方法就是让程序员迟早参与创意过程，与业务专家、客户、产品经理一起参加头脑风暴会议，不断缩小双方思考或理解偏差。有逻辑性的正确设计会节省大量代码，因为编码实践来试错的代价是昂贵的。编码涉及大量技术细节，细到一个字段的字节数都需要考虑，一旦发现代码实现的功能完全不是客户要求的，就只能全部推倒重来。成千上万行代码被删除，好像它们没存在过，他们存在过的意义仅是让程序员明白：此路不通

程序员需要将业务知识的学习和思考结合起来，领域驱动核心就是多了一个领域层，这个领域是业务相关原语，随着业务价值变化而变化，通常每个企业的核心业务域是千差万别的，所以，在技术实现的时候，反复要问我们团队，我们多少比例的代码是针对业务本身，而业务本身对业务消费者有多大的价值？作为业务的技术实现方，一定要有手段通过量化方法，衡量你的业务价值，从而能精细化迭代升级

统一语言，并不是把从客户那里听到的内容翻译成程序自己的语言，减少误解，让客户更容易理解我们的草图，并且真正帮助纠正错误，帮助我们获取有关领域新知识，目标是创造可以被业务、技术和代码自身无歧义使用的共同术语

在PRD文档，设计文档，代码以及团队日常交流中，都使用同一套领域术语，极大地提升沟通和工作效率

简单理解起来的话，也就是把业务人员和开发人员的语言统一起来，用代码来感受一下大概就是：

1
2

userService.love(Jack, Rose) => Jack.love(Rose)
companyService.hire(company,employee) => Company.hire(employee)

通过统一语言，领域驱动设计的核心是建立统一的领域模型。领域模型在软件架构中处于核心地位，软件开发过程中，必须以建立领域模型为中心，以保障领域模型的忠实体现，解决OOAD中OOA分析模型与OOD设计模型割裂的弊端

从知道DDD到现在已经很多年了，看了不少理论知识，在项目中也使用了DDD，碰到些问题，也有些思考，整理一下，上升一下，形成一种适合自身的方法论

在回顾过程中，首先追根溯源，什么是DDD？为什么要使用DDD？如何给别人阐述这些最基本的概念与理念，真是个难题

什么是DDD

DDD已经发展了很多年，现在的一些书也已经不太关注这个基本概念，
平时闲聊时，开口闭口都是DDD，已经不知道DDD的本体是什么，只是听得耳熟，说得顺口了，细细回想下，DDD是个什么？一时语顿，不得找一下Eric Evans大神最原味的解答

DDD来源于Eric Evans的书：
《Domain-Driven Design - Tackling Complexity in the Heart of Software》
领域驱动设计 - 软件核心复杂性应对之道

由此可看出DDD的全称Domain-Driven Design，之前常听到TDD，那何为Domain呢？

书中解释：

每人软件程序都会与其用户的活动或兴趣相关。用户在其中使用程序的主要环境称为软件的领域(domain)

一些领域会涉及到物质世界：航线预订程序的领域涉及到现实中登机的人。一些领域是无形的：财务程序的领域就是货币和金融

领域模型并不是某种特殊的图，而是图所要表达的思想。它并不仅仅是某个领域专家头脑中的知识，而是对相关知识进行严格的组织与选择性抽象

领域模型并不是尽可能地制作一个逼真的模型。即使在一个可触及的真实世界事物的领域中，我们的模型也只是一个仿真的创造物

看到这些，应该还是有点晕，到底是什么？解释这种基本元语，特别的难,有人感觉领域就是业务，那为什么不叫Business Driven Design呢？

有点钻牛角尖的意思，这其实是人类学习新知识的一种惯性思维，从以往经验中寻求类似的事物，帮助理解新事物，好处就可以快速认知新知识，坏处可能永远掌握不了新知识。既然给不了一种清晰的类比解释，那就不求甚解地理解，这个新事务的代名词叫DDD，随着认识的深入，慢慢就会从抽象到具体

但为了提前更好地理解DDD，还是有必要把一些现流行的解读罗列出来

银行业务被银行的内部人员和专家所熟知。他们知道所有的细节、所有的困难、所有可能 出现的问题、所有的业务规则。这些就是我们永远的起始点：领域

领域驱动设计当然不是架构方法，也并非设计模式。准确地说，它其实是“一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发”。领域驱动设计贯穿了整个软件开发的生命周期，包括对需求的分析、建模、架构、设计，甚至最终的编码实现，乃至对编码的测试与重构

领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义

DDD专门解决复杂性的方法论

DDD是面向对象分析的方法论，它可以利用面向对象的特性（封装，多态）有效地化解复杂性，而传统的J2EE等事务性编程只关心数据

DDD作为一种软件开发方法，它可以帮助我们设计高质量的软件模型

由前人的种种总结，粗略可以把DDD理解为一种方法论，一种构造软件模型的方法论

模型

软件的开发目的是什么？软件开发是为了解决由需求带来的各种问题，而解决的结果是一个可以运行的交付物。那么软件设计就是在需求和解决方案之间架设一座桥梁

区别于解决简单的问题，软件的开发往往是一项长期的工作，会有许多人参与其中。在这种情况下，就需要建立起一个统一的结构，以便于所有人都能有一个共同的理解。这就如同建筑中的图纸，懂建筑的人看了之后，就会产生一个统一的认识。而在软件的开发过程中，这种统一的结构就是模型，而软件设计就是要构建出一套模型

模型是对现实世界的简化抽象

根据使用场景的不同，模型大致可以分为物理模型、概念模型、数学模型和思维模型等等

物理模型是拥有体积及重量的物理形态概念实体物体，是根据相似性理论制造的按原系统比例缩小的实物

概念模型是对真实世界中问题域内的事物的描述，是领域实体，而不是对软件设计的描述，它与技术无关。

数学模型是用数学语言描述的一类模型，可以是一个或一组代数方程，微分方程、差分方程、积分方程或统计学方程，也可以是某种适当的组合数学模型

思维模型是用简单易懂的图形、符号或者结构化语言等表达人们思考和解决问题的形式

建立模型有很多方法，并不意味着要用特定符号、工具和流程。无论使用何种建模工具和表示法，只要有助于我们对问题域的理解，均可认为是好的模型。在处理问题时，我们最好隐藏那些不必要的细节，只专注于重要的方面，抓住问题的本质。这就是建模和抽象的价值所在

在软件领域，影响最强的建模工具当属统一建模语言(Unified Modeling Language,UML)

模型，是一个软件的骨架，是一个软件之所以是这个软件的核心。一个电商平台，它不用关系型数据库，还可以用 NoSQL，但如果没有产品信息，没有订单，它就不再是电商平台了

模型的粒度可大可小，一个类是模型，把一整个系统当作一个整体理解，就是个大模型。而常听说的“高内聚、低耦合”其实就是对模型的要求。一个高内聚低耦合的模型能够有效地隐藏细节，让人理解起来也更容易，甚至还可以在上面扩展

在DDD中，模型的选择取决于三个基本用途：

1. 模型与设计核心的相互塑型。正是模型与实现之间密切的联系使得模型与现实相关并且保证对于模型的讨论分析能够应用于最终产品–可运行的程序
2. 模型是所有团队成员所使用语言的核心。由于模型与实现是相互绑定的，因此开发人员可以用这种语言来讨论程序
3. 模型用来提炼知识。模型是团队在组织领域知识和辨别最感兴趣的原理时一致同意的方式

方法论

由上文可知DDD是一种开发方法，那在DDD之前，是怎么进行软件分析设计的呢？一般有两种方法：ER数据建模法和面向对象建模法

在软件的世界里，任何的方法论如果最终不能落在“减少代码复杂度”这个焦点上，那么都是有待商榷的。

ER

这是大多数人进行软件行业时，必学的方法，并且在学生时代，实践课程都是以此为示例，导致这种方法在脑海中根深蒂固

ER数据建模法是在接受到需求以后直接开始数据表ER模型的设计、实体表和表关系的设计

建模过程是一种翻译再表达的过程，其唯一要点就是翻译不走样，如果翻译过程过多引入其他干扰因素和知识，那么无疑会增加翻译的难度和复制的精确性

由于人们对数据库特别看重，SQL普及化，以至将软件的理解浓缩成了CRUD

但由于过于注重数据库技术而忽视了业务上下文。使用CRUD代替业务用语，例如使用“创建订单”替代“下单”，使用“创建帖子”代替“发贴”，使用“创建发票”替代“开票”，虽然也容易让人明白，但“开票”等用语才是真正的业务术语、业务行话，是这个行业内每个人都知晓的。作为软件系统不是去遵循这些用语习惯，而是进行转换改造，按照自己的理解生造出一些词，是不是会潜移默化地将业务需求引导到不同方向呢？

这种方法门槛低，带来了效率的提升，但是高效率不代表高质量，而软件高质量却能带来高效率

OOAD

业务初期，功能比较简单，CRUD基本可以满足。但随着系统的不断演化，业务系统越来越复杂，各模块间有着千丝万缕的关系，如何提升其扩展性

OO最大的宣言就是Everything is object。所有的事物都有两个方面：有什么（属性）：用来描述对象；能够做什么（方法）：告诉外界对象有那些功能。

把人们从低层的SQL计算机语言更加面向人类思维

Object-Oriented Analysis (OOA)：面向对象的分析与设计的侧重点是业务领域分析，与软件所要应用的行业领域相关，而与软件技术关系不大，需要由领域专家进行。这一部分的工作被称为“需求分析”

OOA的成果：

业务领域用例图、活动图、协作图、大量的业务文档资料

Object-oriented design (OOD)，用面向对象的方法为真实世界建立一个计算机中的虚拟模型，OOD的主要任务是跨越业务领域模型与可实际运行的软件系统之间的鸿沟，OOD的难度是非常大的，负责OOD工作的人被称为系统架构设计师

系统架构设计师的任务：

1. 确定系统的总体框架—大多采用已有的领域框架
2. 正确理解需求分析得出的领域模型，用面向对象的思想设计出软件体系结构—系统概要设计
3. 分析现实的可获取的技术资源，分解出软件的各个组件，安排好开发任务流程—系统详细设计

从上面的表述，可以看出面向对象相比ER模型强大多了，但其实面向对象的思想至今都没有真正意义得到普及，至少我是这么认为的。为什么呢？看多少人在进行CRUD这种面向过程式编程就知道了，而且早年的J2EE开发模式，讲究 Web/Service/Dao三层结构。面向过程编程，对象只是数据的载体，没有行为。以数据为中心，以数据库ER设计作驱动。分层架构在这种开发模式下，可以理解为是对数据移动、处理和实现的过程。该对象我们称之为贫血领域对象

贫血领域对象（Anemic Domain Object）：是指仅用作数据载体，而没有行为和动作的领域对象。大量的业务逻辑写在了Service层中，随着业务逻辑复杂，业务逻辑、状态会散落在Service层中的很多处理类或方法中。将数据和行为割裂，原来的代码意图会越来越模糊，代码的理解和维护成本会越来越高。

虽然面向对象没有得到真正的普及，但面向对象还是带来了很多思想，我不确定这些思想是不是面向对象之后才有的，但至少很多思想的确是在学习面向对象后才知道的

比如之前写过一个系列《SOLID》，就是面向对象设计原则

而且像Robert C.Martin认为一个可维护性较低的软件设计，通常由于如下4个原因造成：

1. 过于僵硬Rigidity
2. 过于脆弱Fragility
3. 复用率低Immobility
4. 黏度过高Viscosity

软件工程和建模大师Peter Coad认为，一个好的系统设计应该具备如下三个性质：

1. 可扩展性
2. 灵活性
3. 可插入性

而想规避缺点拥有优点，面向对象设计提供很大的便利，软件的复用(Reuse)或重用拥有众多优点，如可以提高软件的开发效率，提高软件质量，节约开发成本，恰当的复用还可以改善系统的可维护性，这些都是以面向对象设计原则为基础而来

对象与数据表的关系？

在从ER建模转向OOAD时，常把对象类比成表，以前称为表，现在换个名字叫对象，他们好似是一样的，但其实他们的差别很大，就文章开关所述，这是人的经验主义，可能永远掌握不了新知识

数据表是一种数据结构，数据表中的数据是需要SQL去操作的，也就是说，数据结构中的数据是被外部某些行为或函数操作的；虽然对象或类中封装的属性其实也是数据，但对象或类有行为方法，这些行为可以保护被封装的属性数据，外界需要改变对象中的属性数据时，必须通过公开的行为方法才能实现。因此，对象和数据结构两者的区别之一就于在对数据操作是主动还是被动，对象是主动操作数据，而数据结构是被动操作，这一区别使得两种方式下的分析设计思路和编程范式完全不同

表达业务领域中的业务概念时，强调主动操作数据的类或对象更适合表达业务概念，因为业务领域中的业务策略或业务规则都需要动态操作，它们的逻辑性需要主动操作数据完成

设计时，业务对象是定义业务行为，而数据表是定义业务数据结构。一个注重行为，一个注重数据。着重点不同，导致设计要求不同，数据表一旦形成，就不会因为一个特定的应用而进行调整，它必须服务于整个企业，因此，这种结构是许多不同应用之间平衡的选择；而使用对象可以针对具体应用进行设计，将业务行为放入对象中，更能精确反映领域概念，保证业务规则的真正逻辑一致地实现

虽然OOAD很不错，但分析和设计之间常常落差很大，甚至是分裂的。分析阶段的成果不能顺利导入设计阶段，设计阶段引入太多细节而歪曲了分析的宗旨。分析和设计分裂的根本原因是它们导向目标不同，分析人员的目标是从需求领域收集基本概念，是面向需求的，而设计人员则不同，他们负责用代码实现这些概念，因此必须指明能在项目中使用编程工具构建的组件，这些组件必须能够在目标环境(比如java)中有效执行，并能够正确解决应用程序出现的问题。条条大路通罗马，分析人员负责指出罗马方向，而设计人员负责找出通往罗马的某条道路，但是技术细节有时会让这个过程中产生绕路和不必要的复杂性，甚至走错方向，南辕北辙

DDD

【程序员其实不是在编写代码，面是在摸索业务领域知识】

这是很多程序员的真实写照，尤其复杂业务，为什么呢？

很多时候你会遇到这样的情况：一个函数写了几百行，里面的if-else写了一大堆，计算各种业务规则。另一个人接手之后，分析了好几天，才把业务逻辑彻底理清楚。

这个问题从表面来看，是代码写的不规范，要重构，把一个几百行的函数拆成一个个小的函数。从根本上来讲，就是“重要逻辑”隐藏在代码里面，没有“显性”的表达出来

这只是一个函数，推而广之，到类、到模块、到系统，是同样的道理，比如：

业务流程隐藏在多个对象的复杂调用关系里面；
某个业务核心概念没有提取出来，其职责分摊到了其他几个实体里面；
系统耦合，职责边界不清

所以，建模的本质就是把“重要的东西进行显性化，并进而把这些显性化的构造块，互相串联起来，组成一个体系”

而DDD就是为了解决这些痛点，DDD建模思想不同于以往的面向对象分析设计思想，建模和代码之间还存在落差，无法平滑衔接。它将分析和设计完美结合起来，通过引入上下文的特殊性，将项目的真正业务背景和集成复杂性引入设计建模阶段，虽然增加了设计的复杂性，但也提高 了设计的实用性。

领域驱动设计当然不是架构方法，也并非设计模式。准确地说，它其实是“一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发”。领域驱动设计贯穿了整个软件开发的生命周期，包括对需求的分析、建模、架构、设计，甚至最终的编码实现，乃至对编码的测试与重构。

领域驱动设计强调领域模型的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。从业务需求中提炼出统一语言（Ubiquitous Language），再基于统一语言建立领域模型；这个领域模型会指导着程序设计以及编码实现；最后，又通过重构来发现隐式概念，并运用设计模式改进设计与开发质量。这个过程如下图所示：

这个过程是一个覆盖软件全生命周期的设计闭环，每个环节的输出都可以作为下一个环节的输入，而在其中扮演重要指导作用的则是“领域模型”。这个设计闭环是一个螺旋式的迭代设计过程，领域模型会在这个迭代过程中逐渐演进，在保证模型完整性与正确性的同时，具有新鲜的活力，使得领域模型能够始终如一的贯穿领域驱动设计过程、阐释着领域逻辑、指导着程序设计、验证着编码质量。

如果仔细审视这个设计闭环，会发现在针对问题域和业务期望提炼统一语言，并通过统一语言进行领域建模时，可能会面临高复杂度的挑战。这是因为对于一个复杂的软件系统而言，我们要处理的问题域实在太庞大了。在为问题域寻求解决方案时，需要从宏观层次划分不同业务关注点的子领域，然后再深入到子领域中从微观层次对领域进行建模。宏观层次是战略的层面，微观层次是战术的层面，只有将战略设计与战术设计结合起来，才是完整的领域驱动设计

最近一季度KPI中，增加了一项单元测试覆盖率

在之前工作经历中，也有过类似情况，老板开始关注单元测试情况了，就会加上覆盖率这个绩效指标，不管以前如何应对，还是再次关注了一些对于测试的文章，TDD虽然没有大流行，但这个概念还是常被人提起

这张图是在一篇文章中看到的

好写单测的系统往往比不好写单测的系统更加健壮，如果一个系统大部分代码都可以写无 Mock 单测，那么它看起来就像左图一样，外部调用只是薄薄的一层，可以随意更换。

如果你的系统大部分代码都一定要 Mock 才能测试的话，或者根本无法测试的话，就像右图一样，说明你的业务根本就没有自己的核心逻辑，而是和各种外部调用缠绕在一起

这张图让我有很多的感触，值得整理一下思绪

领域模型

这张图跟整洁架构图特别像

中心是核心的业务逻辑，依赖路径是由外向内，外围千变万化，但内核是不变的

不管是设计，还是编码，亦或是UT，都需要这样的思路；需要高内聚，核心业务代码不能分散，集中，有中心脉络

我们有时过多注重了技术层次，比如MVC，我们更多的是关注各层技术变化速率而分层，而忽略了业务层次变化

结合之前分析的《DDD分层》，也应该是三层，但不是MVC，面是是输入、领域、输出三层，类似端口适配器架构

向心力

这可能跟图的形状有关，因为是圆形。所以想到了向心力这个词，业务逻辑要内聚，单元测试也要内聚，当然了，单元测试的内聚是由于业务逻辑的内聚。

而这种高内聚，正合了向心力。没有向心力就是一群散沙，设计是，架构是，团队亦是

功夫在诗外

以前还写过一篇《功夫在诗外》，为了专业有所精进，就去看了很多专业无关的书，似乎方向搞错了，灵感不是平白无故地出现的，而是长年持续思考累积，再因为偶尔一件诗外之事激发，贯穿了之前的整个思考过程

以前看整洁架构那张图怎么没有如此些感悟呢，因为作为一名程序身在其中，但当看到测试内容时，因不是测试人员，身在事外看事，就有了感悟，所以功夫不能完全花费在诗外，也不能离诗过远，才能带来灵感

最近在团队中引入checkstyle ，自动执行规范检查，加入到ci步骤里面，让流程工具化，工具自动化，摆脱人工检查，在团队开发中硬性统一，更便于协作顺畅

checkstyle里面有个规范：所有local variable必须修饰为final

这是为什么呢？

final是Java中的一个保留关键字，它可以标记在成员变量、方法、类以及本地变量上。一旦我们将某个对象声明为了final的，那么我们将不能再改变这个对象的引用了。如果我们尝试将被修饰为final的对象重新赋值，编译器就会报错

这么简单的一个关键字，怎么需要强制修饰一个局部变量

局部变量

class文件

1
2
3
4
5
6
7
8
9

public static void main(String[] args) {
    String name = "Whoops bug";
    int pluginType = 3;
}

public void testFinal(){
    final String name = "Whoops bug";
    int pluginType = 3;
}

两个方法一个局部变量修饰为final,一个不修饰为final

通过javap查看字节码

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

public static void main(java.lang.String[]);
   Code:
      0: ldc           #2                  // String Whoops bug
      2: astore_1
      3: iconst_3
      4: istore_2
      5: return
   LineNumberTable:
     line 13: 0
     line 14: 3
     line 15: 5
   LocalVariableTable:
     Start  Length  Slot  Name   Signature
         0       6     0  args   [Ljava/lang/String;
         3       3     1  name   Ljava/lang/String;
         5       1     2 pluginType   I

 public void testFinal();
   Code:
      0: ldc           #2                  // String Whoops bug
      2: astore_1
      3: iconst_3
      4: istore_2
      5: return
   LineNumberTable:
     line 18: 0
     line 19: 3
     line 20: 5
   LocalVariableTable:
     Start  Length  Slot  Name   Signature
         0       6     0  this   Lcom/jack/lang/LocalFinalTest;
         3       3     1  name   Ljava/lang/String;
         5       1     2 pluginType   I

方法参数与局部变量用final修饰是纯编译时信息，到Class文件里就已经没有踪迹了，JVM根本不会知道方法参数或者局部变量有没有被final修饰

曾经的阿里巴巴规范提出：

推荐】final可提高程序响应效率，声明成final的情况：

（1）不需要重新赋值的变量，包括类属性、局部变量；

（2）对象参数前加final，表示不允许修改引用的指向；

（3）类方法确定不允许被重写

最新规范已经没有这种描述了，R大也回复过这个理由不成立，与性能无关

不变性

按上面class文件看，已经与性能无关，那么只能是它的本性：不变性

final is one of the most under-used features of Java. Whenever you compute a value and you know it will never be changed subsequently put a final on it. Why?

final lets other programmers (or you reviewing your code years later) know they don’t have to worry about the value being changed anywhere else.

If you get in the habit of always using final, when it is missing, it warns people reading your code there is a redefinition of the value elsewhere.

final won’t let you or someone else inadvertently change the value somewhere else in the code, often by setting it to null. final helps prevent or flush out bugs. It can sometimes catch an error where an expression is assigned to the wrong variable. You can always remove it later.

final helps the compiler generate faster code, though I suspect a clever compiler could deducing finality, even when the final is missing. final values can sometimes be in-lined as literals. They can be further collapsed at compile time in other final expressions.

I have got into the habit of using final everywhere, even on local variables and if I am in doubt, I use final on every declaration then take it off when the compiler points out that I modified it elsewhere. When I read my own code, a missing final is a red flag there is something complicated going on to compute a value.

If you reference a static final in another class, that value often becomes part of your class at compile time. The source class then need not be loaded to get the value and the source class need not even be included in the jar. This helps conserve RAM (Random Access Memory) and keep your jars small.

At the machine language level, static finals can be implemented with inline literals, the most efficient form of addressing data.

A little known feature of Java is blank finals. You can declare member variables final, but not declare a value. This forces all constructors to initialise the blank final variables. A final idiom

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

public void test() {
        // Use of final to ensure a variable is always assigned a value,
// and is assigned a value once and only once.
        int a = 4;
        final int x;

        if (a > 0) {
            x = 14;
        } else if (a < 0) {
            x = 0;
        } else {
            x = 3;
        }
        System.err.println(x);
    }

修饰为final是为了解决正确性、合理性、严谨性。用来提醒自己以及其他人，这里的参数/变量是真的不能被修改，并让Java编译器去检查到底有没有被乱改

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

public void testSwitch(){
    final String name;
    int pluginType = 3;
    switch (pluginType) {
        case 1:
            name = "Candidate Stuff";
            //break;
            //should have handled all the cases for pluginType
        case 2:
            name = "fff";
    }
    // code, code, code
    // Below is not possible with final
    //name = "Whoops bug";
}

如果switch遗漏了break，或者switch完整的，在外面给final变量再次赋值，编译器就会报错

类变量

对于final修饰的局部变量有了清晰的认识，再延伸一下final类变量

这儿涉及到一个问题,为什么JUC中很多的方法在使用类final变量时，都在方法中先引用一下

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

public class ArrayBlockingQueue<E> extends AbstractQueue<E>
        implements BlockingQueue<E>, java.io.Serializable {
        /** Main lock guarding all access */
    final ReentrantLock lock;
    
     public int remainingCapacity() {
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            return items.length - count;
        } finally {
            lock.unlock();
        }
    }

Doug Lea给的答复是

It’s ultimately due to the fundamental mismatch between memory models
and OOP
Just about every method in all of j.u.c adopts the policy of reading fields as locals whenever a value is used more than once.This way you are sure which value applies when.This is not often pretty, but is easier to visually verify.
The surprising case is doing this even for “final” fields.This is because JVMs are not always smart enough to exploit the fine points of the JMM and not reload read final values, as they would otherwise need to do across the volatile accesses entailed in locking. Some JVMs are smarter than they used to be about this, but still not always smart enough.

翻译大意：

归根究底是由于内存模型与OOP之间的原则不一致。
几乎j.u.c包中的每个方法都采用了这样一种策略：当一个值会被多次使用时，就将这个字段读出来赋值给局部变量。虽然这种做法不雅观，但检查起来会更直观。
final字段也会做这样处理，可能有些令人不解。这是因为JVM并不足够智能，不能充分利用JMM已经提供了安全保证的可优化点，比如可以不用重新加载final值到缓存。相比过去，JVM在这方面有很大进步，但仍不够智能

1
2
3
4
5
6
7
8

private volatile Integer v1 = 1;


    public void test(){
        Integer a = v1;
        Integer b = v1;
        System.err.println(v1);
    }

看一下字节码

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

public class com.jack.lang.LocalFinalTest {
  private final java.lang.Integer v1;
    descriptor: Ljava/lang/Integer;
public void test();
    descriptor: ()V
    Code:
       0: aload_0
       1: getfield      #3                  // Field v1:Ljava/lang/Integer;
       4: astore_1
       5: aload_0
       6: getfield      #3                  // Field v1:Ljava/lang/Integer;
       9: astore_2
      10: getstatic     #4                  // Field java/lang/System.err:Ljava/io/PrintStream;
      13: aload_0
      14: getfield      #3                  // Field v1:Ljava/lang/Integer;
      17: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
      20: return

使用局部变量引用一下

1
2
3
4
5
6
7
8
9

private final Integer v1 = 1;


public void test(){
    final Integer v2 = v1;
    Integer a = v2;
    Integer b = v2;
    System.err.println(v2);
}

对应字节码

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

public void test();
descriptor: ()V
Code:
   0: aload_0
   1: getfield      #3                  // Field v1:Ljava/lang/Integer;
   4: astore_1
   5: aload_1
   6: astore_2
   7: aload_1
   8: astore_3
   9: getstatic     #4                  // Field java/lang/System.err:Ljava/io/PrintStream;
  12: aload_1
  13: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/Object;)V
  16: return

少了很多次的

1
2

0: aload_0
1: getfield

这就是Doug Lea所讲的没有充分利用JMM已经提供了安全保证的可优化点吗？

其实还有一个关键字与final类似，那就是volatile

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

private volatile FieldType field；  
   
 FieldType getField(){  
    FieldType result = field;  
    if(result == null){  // first check (no locking)  
       synchronized(this){  
          result = field;  
          if(result == null) // second check (with locking)  
             field = result = computeFieldValue();  
       }  
    }  
    return result;  
 }

在单例模式懒汉方式下，加个局部的result变量，会有25%性能会提高（effective java 2第71条）

这儿的性能提升，似乎也是这个原因

其实final和volatile还有更多的内存语义，禁止重排序。但在class文件中没有，使用hsdis与jitwatch查看JIT后的汇编码，可以发现一些端倪

1
2
3
4

0x0000000114428e3e: inc    %edi
0x0000000114428e40: mov    %edi,0xc(%rsi)
0x0000000114428e43: lock addl $0x0,(%rsp)     ;*putfield v1
                                ; - com.jack.lang.LocalFinalTest::test@9 (line 17)

在对volatile写操作时，会加上lock，就是内存屏障store指令

而对于final没有看到相应汇编语句

现在我们以 x86 处理器为例，说明 final 语义在处理器中的具体实现。
上面我们提到，写 final 域的重排序规则会要求译编器在 final 域的写之后，构造函数 return 之前，插入一个 StoreStore 障屏。读 final 域的重排序规则要求编译器在读 final 域的操作前面插入一个 LoadLoad 屏障。

由于 x86 处理器不会对写 - 写操作做重排序，所以在 x86 处理器中，写 final 域需要的 StoreStore 障屏会被省略掉。同样，由于 x86 处理器不会对存在间接依赖关系的操作做重排序，所以在 x86 处理器中，读 final 域需要的 LoadLoad 屏障也会被省略掉。也就是说在 x86 处理器中，final 域的读 / 写不会插入任何内存屏障！

既然没有相应内存屏障指令，那对于类变量加个局部变量，更大的理由就是少了aload、getfield指令

参考资料

final : Java Glossary

https://zhuanlan.zhihu.com/p/136819200

为什么分层

引用《领域驱动设计模式、原理与实践》

为了避免将代码库变成大泥球（BBoM）并因此减弱领域模型的完整性且最终减弱可用性，系统架构要支持技术复杂性与领域复杂性的分离。引起技术实现发生变化的原因与引起领域逻辑发生变化的原因显然不同，这就导致基础设施和领域逻辑问题会以不同速率发生变化

每一层都有各自的职责，显然这也是符合SRP的

如何分层

DDD的标准形态

1. User Interface是用户接口层，主要用于处理用户发送的Restful请求和解析用户输入的配置文件等，并将信息传递给Application层的接口
2. Application层是应用层，负责多进程管理及调度、多线程管理及调度、多协程调度和维护业务实例的状态模型。当调度层收到用户接口层的请求后，委托Context层与本次业务相关的上下文进行处理
3. Domain层是领域层，定义领域模型，不仅包括领域对象及其之间关系的建模，还包括对象的角色role的显式建模
4. Infrastructure层是基础实施层，为其他层提供通用的技术能力：业务平台，编程框架，持久化机制，消息机制，第三方库的封装，通用算法，等等

根据DDD细化业务逻辑层

模块

结合maven的module,项目中现在分了八个module

1
2
3
4
5
6
7
8
9
10

<modules>
    <module>generator-assist-dao</module> <!-- 生成的dao -->
    <module>generator-assist-client-api</module> <!-- swagger api yaml -->
    <module>assist-client-api</module> <!-- 生成的api -->
    <module>assist-controller</module> <!-- controller -->
    <module>assist-service</module> <!-- domain -->
    <module>assist-infrastructure</module> <!-- infrastructure -->
    <module>assist-common</module> <!-- 基础common -->
    <module>start</module> <!-- 启动入口及test -->
</modules>

start

入口模块

包结构：

• start 只有一个启动类
• test 单元测试

除了启动类，还有单元测试

generator-assist-dao

生成的dao类

包结构：

• repository
  • model 与数据库对应的实体类
• repository
  • mapper mybatis的mapper

现在实践落地时，这个模块是个空模块，why?

DDD中明确了repository概念，并属于domain层，但dao是对底层数据库的封装，具体实现类放在infrastructure层更合理

在COLA中，作者也是为了领域层的纯洁性，依赖反转了，repository接口定义在domain层，而实现在infra层

但在落地时，domain与infra出现了循环依赖，COLA把实现放在了app层，这样有些另类，所以暂时先把repository全部放在了service层

迷思：

1、基于mybatis的实现，mapper本身是接口，repository实现类放在domain层，不要接口，这样满足DDD分层规则，但离DIP差了一步

2、在《DDD之熵》中提过

DDD引入repository放在了领域层，一是对应聚合根的概念，二是抽象了数据库访问，，但DDD限界上下文可能不仅限于访问数据库，还可能访问同样属于外部设备的文件、网络与消息队列。为了隔离领域模型与外部设备，同样需要为它们定义抽象的出口端口，这些出口端口该放在哪里呢？如果依然放在领域层，就很难自圆其说。例如，出口端口EventPublisher支持将事件消息发布到消息队列，要将这样的接口放在领域层，就显得不伦不类了。倘若不放在位于内部核心的领域层，就只能放在领域层外部，这又违背了整洁架构思想

3、是不是有别的理论支撑解决问题2

generator-assist-client-api

为了生成api的swagger yaml文件

包结构：

• swagger-spec
  • all swagger所有yaml文件的整合文件
  • apis swagger定义的api
  • models swagger定义的api中的model
• swagger-templates 模板文件

assist-client-api

通过swagger生成的api接口与api中的model

包结构：

• client
  • api swagger生成的api接口
  • model swagger生成的request,response对象

assist-controller

controller层，放置controller

包结构：

• controller 所有的controller
• xxljob xxljob补偿任务

按DDD分层规范，controller属于ui层，处理restful请求

• 接受请求 —— 由spring提供能力
• 请求格式校验及转换 —— 格式校验遵循java Validation规范
• 权限校验 —— 由网关处理
• 路由请求 —— 网关处理
• 记录请求 —— 专门Accessfilter处理
• 回复响应 —— 由spring提供能力

为什么还有一个xxljob包，从能力区分，xxljob放到infra层才对。这个原因类似generator-assist-dao模块，xxljob的handler需要调用application service，需要依赖service module

因此可以把xxljob作为远程请求的一个入口，与controller一样归在ui层

这儿引出一点思考，controller真的是ui层吗？能划分到别的层吗？

有几种设计思路

1. ui层完全归属于大前端，不在后端，也就不在ddd中，后端都是从application service开始
2. controller归于ui
3. controller归于infra，controller毕竟是依赖具体底层框架能力的adapter

controller是基于springboot的具体实现

从上面的分析，可以看出controller逻辑上是归到infra层，但物理上不能放到infra模块；也不能简单把controller看作MVC中的C，还有很多像xxljob样的入口

1. 入口会有很多，如controller、xxljob，还有mq等等
2. 还有进程内的，如event，应用层，基础设施层，领域层都有event，怎么区分event是个问题
3. application serivce与domain service区分也常常给人带来烦恼

这儿是否可以借鉴《DDD之形》中的端口和适配器架构

把controller看作driving adapter，既然区分这么复杂，那可不可以简单点，加厚controller，整合入口与application service

简单点分成两部分：远程服务与本地服务

• 远程服务：定义会跨进程服务，分为资源（Resource）服务、供应者（Provider）服务、控制器（Controller）服务与事件订阅者（Event Subscriber）服务
• 本地服务：所有远程服务需要调用领域服务，必须经过本地服务才能调用；明确隔离外界与领域，防止领域模型外泄

assist-service

domain层，但现在还是三层结构的思路，什么类都有，app service，domain service，dto,event 甚至还有基础设施层类

包结构

• BO
• builder
• common
• component
• convertor
• domain
• dto
• event
• interceptor
• listener
• model
• repository
• service
• thrid
• valid

assist-infrastructure

基础设施层

包结构

• config 配置信息
• adapter 外部调用封装
  • clients 外部调用实现
  • pl 服务接口的契约 published language
• dp domain primitive 这是不是应该在domain层
• common 公共类，(InvoiceType与InvoiceTypeEnum的问题)
• event
  • publish 事件发布者，此包为空，直接依赖spring不需要自实现了
• exception 异常类
• gateway 网关，封装访问外部系统或资源行为的对象
  • wechat 外部名称
    • api 外接接口
    • dto 外接接口dto
• local
  • pl
• ports
  • clients 外部调用接口
• repository
  • model
• resources 资源
• service 依赖外部的service
• util 工具类

现在的包结构很丰富，最常见的包就是gateway，配合acl与外部交互

U表示上游（Upstream）的被依赖方，D表示下游（Downstream）的依赖方。防腐层（ACL）放在下游，将上游的消息转化为下游的领域模型

结合generator-assist-dao模块的问题，是否可以扩大ACL，而不仅限于gateway中,像资源库一样，不必完全遵循DDD只抽象repository，像访问第三方应用，缓存，消息都可以抽象出来，契合端口履行的职责一样

改造

1
2
3
4
5
6
7
8
9

<modules>
    <module>generator-assist-dao</module> <!-- 生成的dao -->
    <module>generator-assist-client-api</module> <!-- swagger api yaml -->
    <module>assist-client-api</module> <!-- 生成的api -->
    <module>assist-ohs</module> <!-- ohs -->
    <module>assist-service</module> <!-- domain -->
    <module>assist-acl</module> <!-- acl -->
    <module>start</module> <!-- 启动入口及test -->
</modules>

assist-controller

根据上面的分析，这一层可以更厚实些

改名为assist-ohs

OHS,open host service 开放主机服务，定义公开服务的协议，包括通信的方式、传递消息的格式（协议）

包结构

• remote
  • controller
  • openapi
  • xxljob
  • subscribe
• local
  • appservices
  • pl (plush language) request,response
  • convertor

assist-service

domain层

包结构

• domain 领域对象
• service 领域服务
• factory 领域对象工厂
• builder 领域对象构造器

assist-acl

扩大了基础设施层，隔离领域层与外部依赖，对所有外部环境一视同仁，无需针对资源库做特殊化处理，如此也可保证架构的简单性，repository、client、cahce…

领域层依赖port接口

包结构

• config 配置信息
• port 依赖外部接口
  • repository 数据库接口
  • client 第三方系统接口
  • publisher 消息接口
  • cache 缓存接口
• adapter port的具体实现
  • repository
  • pl
  • client

总结

模块划分以及包结构还只是一家之言，一是有充足的理论体系支撑，不管按DDD标准，还是变形，更多地有理有据，与团队、也与自己达成一致；二是domain的抽象，一切都是为了领域模型的稳定性和扩展性，形只是表象

我们这个项目还是太注重了形，最重要的domain还是过弱

根据上一篇【死锁分析】，又重新梳理了一下，画图表示更形象一些

update ? where user_id=? and tenant_id=? and no=?;如果先走（tenant_id,user_id） 则是日志一

先走no，则是日志二

索引交叉，则是日志三

最近借着死锁事项，又温习了部分数据库的理论知识，后面有时间再整理。现在的程序员真难，得上知天文，下知地理；这应该是DBA的专长，作为开发也得去深究，真难

在追查死锁的过程中，对照理论有一些实践，总结一下：

查看事务自动提交选项

1
2
3
4
5

show session variables like 'autocommit';
show global variables like 'autocommit’;

set session autocommit=0;
set global autocommit=0;

查看事务隔离级别

1

select @@tx_isolation

查看锁信息，想查看一条sql使用了什么锁，需要打开锁监听

1
2
3
4
5
6
7
8
9

show session variables like '%output%';

#开启InnoDB锁监控
set global innodb_status_output_locks=on;

set global innodb_status_output=on;
#上面的语句可定期写入到标准错误输出（stderr，即error log，大概每15s写一次），你也可以使用 SHOW ENGINE INNODB STATUS 语句直接在客户端获取innodb信息

show session variables like '%output%';

要启用InnoDB锁定监视器的 SHOW ENGINE INNODB STATUS输出，只需启用innodb_status_output_locks

打开监控开关后，在mysql日志文件中会出现

1
2
3
4
5
6
7

=====================================
2020-06-30 15:44:46 7fdc8a76e700 INNODB MONITOR OUTPUT
=====================================

----------------------------
END OF INNODB MONITOR OUTPUT
============================

打开锁监控，可以确定一下常用语句的锁信息

执行完一条SQL，使用SHOW ENGINE INNODB STATUS打印出锁信息

1
2
3
4

delete from invoice_collection_info where id=1275244823997059072

TABLE LOCK table `assist`.`invoice_collection_info` trx id 1636893 lock mode IX
RECORD LOCKS space id 18491 page no 211 n bits 104 index `PRIMARY` of table `assist`.`invoice_collection_info` trx id 1636893 lock_mode X locks rec but not gap

delete语句，根据主键删除操作；可以明显看出上了表锁IX model,还有一个主键索引锁

其实如果有二级索引，还会有二级索引锁，但那是隐式锁，所以没有显示出来，后面会有试验让隐式锁显示化

使用二级索引删除操作

1
2
3
4
5
6
7
8
9
10

delete FROM invoice_item WHERE ( collection_id = 1275244823997059072 );

TABLE LOCK table `assist`.`invoice_item` trx id 1636964 lock mode IX
RECORD LOCKS space id 18493 page no 4 n bits 784 index `idx_collection_id` of table `assist`.`invoice_item` trx id 1636964 lock_mode X locks rec but not gap
Record lock, heap no 563 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 0: len 8; hex 91b2946930001000; asc    i0   ;;
 1: len 8; hex 91b2ae5d61401000; asc    ]a@  ;;

RECORD LOCKS space id 18493 page no 12 n bits 96 index `PRIMARY` of table `assist`.`invoice_item` trx id 1636964 lock_mode X locks rec but not gap
Record lock, heap no 28 PHYSICAL RECORD: n_fields 23; compact format; info bits 0

先在二级索引上加锁，再在对应的主键索引上加锁

使用二级索引查询

1
2
3
4
5
6

select * from invoice_collection_info where invoice_uiq_flag = '031001900104-62079412' for update

TABLE LOCK table `assist`.`invoice_collection_info` trx id 1636947 lock mode IX
RECORD LOCKS space id 18491 page no 642 n bits 344 index `idx_uniflag` of table `assist`.`invoice_collection_info` trx id 1636947 lock_mode X locks rec but not gap

RECORD LOCKS space id 18491 page no 496 n bits 96 index `PRIMARY` of table `assist`.`invoice_collection_info` trx id 1636947 lock_mode X locks rec but not gap

从日志中看出，先在invoice_uiq_flg二级索引上加锁，再在主键索引加锁

使用主键更新操作

1
2
3
4

update invoice_collection_info set invoice_uiq_flag = '031200190010-62079412' WHERE (  id = 1275244823997059072 );
 
TABLE LOCK table `assist`.`invoice_collection_info` trx id 1636958 lock mode IX
RECORD LOCKS space id 18491 page no 741 n bits 88 index `PRIMARY` of table `assist`.`invoice_collection_info` trx id 1636958 lock_mode X locks rec but not gap

其实不仅会在主键加X，还会在二级索引上也加X，但没有显示出来；这儿跟delete一样，其实也是个隐式锁

模拟测试了一下，两条sql，一条根据二级索引删除操作、另一条使用主键更新记录模拟并发死锁，把update中的二级索引锁显示出来了

上面的操作都是在RC级别下进行的，对于select操作，快照读都不会加锁，实验结果也与理论一致

最近新项目上线，在压测和发布生产都出现了好几种死锁情况，分析一二

死锁日志

日志一：

日志二：

日志三：

这三个死锁日志特别的有意思，都是同一条SQL，但各种组合样的死锁都齐活了

日志一的两条sql，where里面的条件不同；

日志二和日志三sql完全一样，其实是两次调用(同一时刻并发调用)，调用条件不同，但在程序处理时这条SQL的where条件一样而已

分析

隔离级别RC

日志一，where里面的条件不同

第一个事务在等待RECORD LOCKS，锁模式为X model;位置在space id 428 page no 178

第二个事务持有RECORD LOCKS，锁模式为X model;位置也在space id 428 page no 178；等待的锁也是RECORD LOCKS，锁模式为X model，也在space id 428 page no 178

这个死锁很是奇怪，同一条sql，都是在索引【idx_tenant_user】上加锁，完全不符合死锁的循环等待特征

这张表上的索引

1
2
3

KEY `idx_collection_no` (`collection_no`) USING BTREE,
KEY `idx_uniflag` (`invoice_uiq_flag`) USING BTREE,
KEY `idx_tenant_user` (`tenant_id`,`user_id`) USING BTREE

通过explain查看此语句

索引上看使用idx_tenant_user,也与死锁日志一致，但怎么就死锁了呢？

【SHOW ENGINE INNODB STATUS;】只能显示最终发生死锁时的sql,并不能显示全部的sql，从程序上下文中寻找，发现点蛛丝马迹

事务2在T1时刻执行了一条根据id更新数据的sql，这条sql会在id聚簇索引上加X锁，还会在二级索引上加X锁，所以先获得了(user_id,tenant_id)锁，

事务1在T2时刻只能等待

事务2在T3时刻形成了循环等待，deadlock

日志二,sql完全一样

与前面解释，两个并发请求，入参不同，但到这个方法时，sql的条件是一样的

日志三，sql也完全一样

虽然与日志二的SQL一样，但死锁日志却不同

为什么同样的SQL，却得出各样的结果？时而collection_no索引在前，时而组合索引在前

苦思几日，在线上跑了下explain，发现了些问题

原来线上使用的index merge

有官网上有介绍：https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html

MySQL在分析执行计划时发现走单个索引的过滤效果都不是很好，于是对多个索引分别进行条件扫描，然后将多个索引单独扫描的结果进行合并的一种优化操作。合并的方式分为三种：intersection、union和sort_union

index merge 之 intersect,简单而言，index intersect merge就是多个索引条件扫描得到的结果进行交集运算。显然在多个索引提交之间是 AND 运算时，才会出现 index intersect merge.

正因为index merge,所以索引的真正执行顺序是不一样的，也就造成了各种表象

解决

建立联合索引

都使用主键更新

关掉参数index_merge_intersection=off，禁用index_merge功能

参照

MySQL 优化之 index_merge

一个 MySQL 死锁案例分析

早时总结过《ThreadLocal解析》、《FastThreadLocal解析》

最近看些资料时，又注意到这个类，不尽想再重温下，很多知识点，之前已经总结了，此篇主要有两个问题：

1、弱引用的意义

2、如何防key冲突

弱引用

ThreadLocal底层使用的ThreadLocalMap一直在进化中，早在JDK1.3时代还是使用的普通的HashMap，后来才改写成ThreadLocalMap

这个ThreadLocalMap有两个特殊之处，一是使用了线性探索法，详情见《Hashmap源码解析》；二是key使用了弱引用

1
2
3
4
5
6
7
8
9
10
11

/**
 * ThreadLocalMap is a customized hash map suitable only for
 * maintaining thread local values. No operations are exported
 * outside of the ThreadLocal class. The class is package private to
 * allow declaration of fields in class Thread.  To help deal with
 * very large and long-lived usages, the hash table entries use
 * WeakReferences for keys. However, since reference queues are not
 * used, stale entries are guaranteed to be removed only when
 * the table starts running out of space.
 */
static class ThreadLocalMap{}

从注释可以看出作者为什么使用弱引用，为了处理大对象和长周期对象，在GC时可以主动回收

一直感觉这儿的弱引用设计是个鸡肋

在实际使用中，还是会出现内存泄漏，何必使用弱引用呢？

在ThreadLocal的类注释中

1
2
3
4
5
6

This class provides thread-local variables.  These variables differ from
 * their normal counterparts in that each thread that accesses one (via its
 * {@code get} or {@code set} method) has its own, independently initialized
 * copy of the variable.  {@code ThreadLocal} instances are typically private
 * static fields in classes that wish to associate state with a thread (e.g.,
 * a user ID or Transaction ID).

建议使用static修饰

阿里规范也有此建议：

【参考】ThreadLocal 对象使用 static 修饰，ThreadLocal 无法解决共享对象的更新问题。 说明:这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量， 也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义的)都可 以操控这个变量。

在 stackflow上点赞比较多的回答：

Because if it were an instance level field, then it would actually be “Per Thread - Per Instance”, not just a guaranteed “Per Thread.” That isn’t normally the semantic you’re looking for.

Usually it’s holding something like objects that are scoped to a User Conversation, Web Request, etc. You don’t want them also sub-scoped to the instance of the class.
One web request => one Persistence session.
Not one web request => one persistence session per object.

结合实际项目中都是使用线程池的，所以线程基本也是常驻内存的，根据建议使用static修饰，根本没有被回收的机会，虽是弱引用，但一直被强引用

所以何必呢，还让这个点成为一个常备的面试题，同是程序员，非得难为自己人呢！

上面的结论其实还是从大多数人的思维方式思考的，就是提到ThreadLocal都会与线程联系上，在线程的背景里讨论ThreadLocal

但从类注释上看，它是个变量：This class provides thread-local variables，所以还是从变量角度考虑

从变量范围讲，有类变量，局部变量，那ThreadLocal就是线程范围内的变量

根据变量的作用域，可以将变量分为全局变量，局部变量。简单的说，类里面定义的变量是全局变量，函数里面定义的变量是局部变量。

还有一种作用域是线程作用域，线程一般是跨越几个函数的。为了在几个函数之间共用一个变量，所以才出现：线程变量，这种变量在Java中就是ThreadLocal变量。

全局变量，范围很大；局部变量，范围很小。无论是大还是小，其实都是定死的。而线程变量，调用几个函数，则决定了它的作用域有多大。

ThreadLocal是跨函数的，虽然全局变量也是跨函数的，但是跨所有的函数，而且不是动态的。

ThreadLocal是跨函数的，但是跨哪些函数呢，由线程来定，更灵活

1
2
3
4
5
6
7
8
9
10
11

public class ThreadLocalDemo
{
	public static void main(String[] args)
	{
		ThreadLocal<Integer> count = new ThreadLocal<Integer>();
		//使用count
		count.set(10);
		// count不再被使用，可以进行内存回收
		System.out.println("");
	}
}

这个示例中，count要不要被回收

我想，此时JDK的作者也是左右为难，从眼见为实的角度来说，变量不用了就应该进行回收，实现内存的自动回收，这是Java给人最大的特点。

但是，此时不能回收count，因为它与10绑定到了一块，而且只能通过count才能读写10。最后JDK作者耍了一个小聪明，用弱引用包装了count，没有干脆利索的进行内存回收，而是拖拖拉拉的进行回收，反正，最后实现了变量不用就回收的基本原则，与Java的传统思想一脉相承

到此，应该是知道为什么作者要设计为弱引用了，按建议使用ThreadLocal,修饰为static,就不是为了防内存泄漏，而只是为了达到java变量不使用就回收的基本原则，只是在线程范围时，只能曲线救国了

防碰撞

在hash数据结构中，最重要的一点就是如何更好地设计，尽量避免key的冲突

普通的hashmap使用的是拉链法，把长度设置成2的N次方，还有负载因子

ThreadLocalMap使用的线程探索法，作者使用了哪些奇技淫巧

map的长度

1
2
3
4

/**
 * The initial capacity -- MUST be a power of two.
 */
private static final int INITIAL_CAPACITY = 16;

ThreadLocalMap没有设置容量的方法，一般情况下，也不会实例化那么多ThreadLocal实例

必须是2的N次方，这个特性在HashMap中一样，就不解释了，详情见《Hashmap源码解析》

负载因子

在hashmap中，默认负载因子为了0.75，在ThreadLocal中呢？

1
2
3
4
5
6

/**
 * Set the resize threshold to maintain at worst a 2/3 load factor.
 */
private void setThreshold(int len) {
    threshold = len * 2 / 3;
}

看出负载因子为2/3

但threadlocalmap还有特别的地方，就是弱引用，key可能变成null，所以在get,set都会清理key为null的Entry

1
2
3
4

tab[i] = new Entry(key, value);
int sz = ++size;
if (!cleanSomeSlots(i, sz) && sz >= threshold)
    rehash();

再看rehash();

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

/**
 * Re-pack and/or re-size the table. First scan the entire
 * table removing stale entries. If this doesn't sufficiently
 * shrink the size of the table, double the table size.
 */
private void rehash() {
    expungeStaleEntries();

    // Use lower threshold for doubling to avoid hysteresis
    if (size >= threshold - threshold / 4)
        resize();
}

rehash方法并不是直接就rehash了，会先清理过期元素，再判断size>= threshold-threshold/4

threshold=len * 2 / 3

threshold-threshold/4=len 2 / 3-(len 2 / 3)/4= len/2

所以最终是在清理过期元素后，元素数量超过len/2时，就会正式扩容两倍

0x61c88647

hash函数的设计是hash类数据结构的一个重点，空间与时间的平衡是关键

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

/**
 * ThreadLocals rely on per-thread linear-probe hash maps attached
 * to each thread (Thread.threadLocals and
 * inheritableThreadLocals).  The ThreadLocal objects act as keys,
 * searched via threadLocalHashCode.  This is a custom hash code
 * (useful only within ThreadLocalMaps) that eliminates collisions
 * in the common case where consecutively constructed ThreadLocals
 * are used by the same threads, while remaining well-behaved in
 * less common cases.
 */
private final int threadLocalHashCode = nextHashCode();

/**
 * The next hash code to be given out. Updated atomically. Starts at
 * zero.
 */
private static AtomicInteger nextHashCode =
    new AtomicInteger();

/**
 * The difference between successively generated hash codes - turns
 * implicit sequential thread-local IDs into near-optimally spread
 * multiplicative hash values for power-of-two-sized tables.
 */
private static final int HASH_INCREMENT = 0x61c88647;

/**
 * Returns the next hash code.
 */
private static int nextHashCode() {
    return nextHashCode.getAndAdd(HASH_INCREMENT);
}

每当创建ThreadLocal实例时这个值都会累加 0x61c88647

0x61c88647转化成十进制：2654435769为32位无符号整数的黄金分割值，而-1640531527就是32位带符号整数的黄金分割值

当容量为2的N次方，并且使用上这个魔法值后，元素经过散列算法后恰好填充满了整个容器，也就是实现了完美散列

对于这个数字由来，我也大致搜索了些资料，这已经超出作为一名码农的能力范围，只能反思数学老师讲的：不是数学用不上，而是你没有用上的能力

环形

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

/**
 * Increment i modulo len.
 */
private static int nextIndex(int i, int len) {
    return ((i + 1 < len) ? i + 1 : 0);
}

/**
 * Decrement i modulo len.
 */
private static int prevIndex(int i, int len) {
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

在寻找下一个位置时，虽然threadlocalmap是线性探索，但逻辑上使用环形结构，这个与防冲突关系不大，但也是个知识点，一并罗列下

参考

一针见血 ThreadLocal

Why 0x61c88647?

ThreadLocal源码——黄金分割数的使用