csdn_9527666的博客

原创 Image

原创 无状态服务和有状态服务

原创 ApplicationContext的孩子们

ConfigurableApplicationContext继承了ApplicationContext 获得了其所有能力：环境、可列举获取bean的容器、层级关系的容器、消息、事件发送、资源解析器继承了Lifecycle 获得了生命周期管理的 开启组件、停止组件、获取当前组件是否运行的能力继承了Closeable 获得了关闭IO流的能力增加了 设置唯一ID、设置父容器、设置环境、增加后置处理器、增加应用监听器、增加资源解析器、刷新配置等配置能力。...

原创 大数据比较问题

问题1两个分别有60亿字节(Byte)的文件存储了空格隔开的IP地址，现提供4核CPU 以及 12G 内存机器，目标是找出两个文件共有的IP地址并存储到文件C中。解答11 容量规划：60亿字节 = (60 * 10 ^ 8) / 1024 / 1024 = 5.5GB2 暴力法:读取其中A文件到内存中(Set去重存储)，循环分片读取B文件，如在A 中存在则将其加入到C文件中，并从缓存中删除避免重复加入C中。多线程加速:对B 文件 按照线程数目进行分片， 写A缓存和C文件时会存

原创 ApplicationContext 继承的接口

1Object getBean(String name) throws BeansException;为实现这个接口需要1.1 线程安全的数据结构保存bean的定义信息1.2 可以通过bean的ID和类型找到这个bean定义1.3 线程安全的数据结构保存已创建过的对象(单例bean实例复用)1.4 父子容器，子容器无时从父容器中找1.5 需要判断bean的作用域2 <T> T getBean(String name, Class<T> requ...

原创 Spring 的一些思考

遵循带着目的去看源码学习的规则，研究源码前先提出问题:1 bean 注入方式 按照指定id注入 按照class的type注入问题 如id重复 在同一个xml文件中会报错 在多个xml文件中在后面加载的bean 同一个id会覆盖之前加载的bean2 配置bean 为什么需要class属性? 反射加载bean 是不是需要类的全限定名，也就是坐标?3 property set注入 constructor-arg 构造器注入的源码实现4 所有的bean交给Spring管理，...

原创 为什么HashMap负载因子达到0.75 就要扩容?

为什么选择了0.75作为HashMap的加载因子呢？这个跟一个统计学里很重要的原理——泊松分布有关。描述单位时间内随机事件发生的次数的概率分布。P 表示概率，N表示某种函数关系，t 表示时间，n 表示数量，λ 表示事件的频率。随机哈希码，在扩容阈值（加载因子）为0.75的情况下，节点出现在频率在Hash桶（表）中遵循参数平均为0.5的泊松分布。忽略方差 则 lambda * t = 0.5 此时*0:0.60653066*1:0.30326533*2...

原创 hash冲突解决

1 开放寻址法如冲突则根据指定步长向后寻找直到找到空位或没有位置步长算法:1.1 线性探查 步长为1 如threadlocalkey1：hash(key)+0key2：hash(key)+1key3：hash(key)+21.2 平方探测法 计算下一次的步长key1：hash(key)+0key2：hash(key)+1^2key3：hash(key)+2^21.3 随机探测法 步长为随机生成的数 疑问：查询时如何查？如遍历查询有何意义？缺点：查找性...

原创 缓存数据一致性

主要来源自 美团点评 张韩文章:https://maimai.cn/article/detail?fid=1057432698&efid=vnXzd0cl0pDwUW6f6iMpGA&from=groupmessage为什么会有缓存数据一致性问题（Why）数据变更更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库？总结为下面四种更新策略...

原创 控制软件复杂度的原则

导致软件系统变得复杂的成因是规模、结构与变化三要素控制复杂度的原则：就需要对 规模、结构与变化 逐个击破规模保证系统的小规模，分而治之，小即是美在应对新需求时，不会直接去修改一个复杂的旧系统，而是通过添加新特性，然后对这些特性进行组合。要满足小程序之间的自由组合，就需要满足第二条原则，即每个程序的输入和输出都是统一的，因而形成一个统一接口（Uniform...

原创 金字塔原理读书笔记 一 为什么使用金字塔结构

Why表述相同的内容，使用金字塔结构自顶向下展开供受众阅读，受众更容易掌握全局思想。How1 归类分组，将思想组件成金字塔举例：买生活用品由于没有对所需物品分类整理，受众很难记住2 对每个分类进行抽象概括如 葡萄、橘子、苹果 都是水果自上而下表达：结论先行自上而下的将信息传递给受众。更易于让受众快速理解。自下而上思考：总结概括...

原创 金字塔原理读书笔记 零 序言

1 金字塔结构组织的思想和 未能经过组织的思想2 受众最容易理解的顺序：先 主要的、抽象的思想（结论） 再 次要的、为主要思想提供支撑的思想（论据）结论是由论据推理得出，先有论据再有结论。传播给受众要反转顺序。3 为什么 先结论 再论据 的阐述顺序更容易被受众接受？受众首先看到结论后 会产生多个疑问（参见学会提问），而论据就是对疑问的解答。通过 疑问/回...

原创 代码模型的架构决策

代码模型 体现了 代码模块的 结构层次架构视图中 代码模型 作为其中一个视图 展现模块的 划分 定义运行时实体 与 执行视图建立联系​代码模型的设计可以分为两个层次，具体如下。 系统层次：设计整个软件系统的代码模型。 限界上下文层次：设计限界上下文内部的代码模型。 针对整个软件系统，我们可以将这些限界上下文视为一个黑盒子。仅需关心限界上下文暴露的接口以及它...

原创 代码模型

在 理解了 限界上下文 以及 分层架构 的本质基础上 需要确认系统的代码模型每个团队 无需 都遵守一套 代码模型在同一个项目中 必须 1遵守 同一个代码模型 并需要 2 知道 如此划分代码的 意义 与价值代码模型设计之前已经分析过1 层与层之间的协作2 跨限界上下文之间的协作考虑限界上下文的代码模型时，需要考虑纵向架构除前端之外的所有层次或模块...

原创 限界上下文与架构

限界上下文对 领域驱动架构 有直接到影响识别限界上下文 与 上下文映射 都是重要过程限界上下文是 逻辑架构 以及 物理架构的 参考模型上下文映射体现了系统架构的通信模型限界上下文不仅仅作用于领域层 以及 应用层是架构设计 而非仅仅领域设计的关键因素限界上下文 是一个 垂直的 架构边界针对后端架构层次的垂直拆分例如：订单上下文的内部就包含...

原创 DDD各层次职责与协作关系

架构演进得到了 符合DDD思想的分层架构 是一种静态逻辑划分实现业务用例时，各层之间是怎么协作的？辨别动态协作关系的方法：从职责的角度入手，清楚地理解分层架构中每个层次的职责案例：电商系统的下订单场景在买家提交订单时，除了与订单直接有关的业务之外，还需要执行以下操作： 订单数据的持久化：OrderRepository 提供插入订单功能。它属于...

原创 DDD的演进

演进领域驱动架构的着手点：1 避免领域模型出现贫血模型2 保证领域模型的纯粹性避免贫血的领域模型经典三层架构中1 领域逻辑 在 业务逻辑层的service对象中2 反映了领域概念的 领域对象 被定义为Java Bean 此 Java Bean未包含任何领域逻辑 被放在 数据访问层3 DAO 对象仅负责与数据库的交互，并实现领域对象到数据表的 CRUD（增删...

原创 分层架构的演化

架构设计最高原则： 高内聚、松耦合 的软件系统架构整洁架构设计出干净的应用层 以及 领域层 仅仅关注业务逻辑 不包含任何 具体技术实现优点：完成领域与技术之间的完全隔离领域模型就是业务逻辑的模型，它应该是完全纯粹所有领域模型对象都应该是 POJO（Plain Ordinary Java Object）。POJO 指的是一个普通的 Java 对...

原创 分层架构基础

为什么要将业务与基础设施分开？答：引起它们变化的原因不同 单一职能原则的体现经典分层架构最为经典的就是三层架构以及领域驱动设计提出的四层架构。经典三层架构：用户界面层（User Interface Layer）、业务逻辑层（Business Logic Layer）与数据访问层（Data Access Layer） 如下图所示：​流行原因：系统复杂...

原创 辨别限界上下文的协作关系

1 是否存在关系2 是何种关系3 基于变化导致的影响来确定是否需要引入防腐层、开放主机服务等模式4 发现协作关系有不合理之处，则需要反思之前我们识别出来的限界上下文是否合理。限界上下文通信边界对协作的影响怎么做：如何确定限界上下文之间的关系？1 全面考虑参与到两个限界上下文协作的业务场景2 在场景中识别二者之间产生依赖的原因3 确定依赖的方向，进而确定集成点...

原创 上下文映射的通信集成模式

防腐层与开放主机服务目的：降低限界上下文之间的耦合关系防腐层：（下游限界上下文对 上游限界上下文变化的隔离）是什么：设计思想“间接”的一种体现方法：通过引入一个间接的层，就可以目的：有效隔离限界上下文之间的耦合设计模式：间接的防腐层还可以扮演“适配器”的角色、“调停者”的角色、“外观”的角色防腐层往往属于下游限界上下文，用以目的：隔绝上游限界上下文可能发...

原创 上下文映射的团队协作模式

原则： 各司其职 权责分明从组织角度看：预防一个团队 权利膨胀 团队势力扩大到整个组织从团队角度看：避免自己权利被压缩，导致话语权减小如何平衡？满足合理分配职责的前提下，谨慎地确保每个限界上下文的粒度。领域驱动设计根据团队协作的方式与紧密程度，定义了五种团队协作模式：合作关系：合作得越多，就意味着依赖越多：二者可能存在强耦合关系，甚至是糟糕的双向依赖...

原创 上下文映射

降低业务复杂度的有效手段：分治法软件设计难题： 如何分 限界上下文如何确定限界上下文之间怎么合： 上下文映射分是合的基础 隔离是复用的前提上下文映射：“合”就是要尽可能地降低 不同上下文 之间的耦合。意义：解决限界上下文之间的协作问题上下文映射图：​U 代表上游，D 代表下游上游产生的变化会影响到下游 下游依赖于...

原创 从应用边界识别限界上下文

质量属性：关乎质量属性的问题 视为在将来可能会发生，其实就是“风险（Risk）”。架构是重要的东西，是不容易改变的决策。未曾预测到系统存在的风险，不幸它又发生了，带给系统架构的改变可能是灾难性的为什么说限界上下文是领域驱动设计中最重要的元素？：原因：限界上下文的边界，就可以将这种风险带来的影响控制在一个极小的范围更改了技术选型，选择基于 Elastic...

原创 从工作边界识别限界上下文

限界上下文划分业务边界: 从业务相关性（内聚）判断业务的归属基于团队合作划分工作边界: 帮助我们确定限界上下文合理的工作粒度按照团队合作的角度划分限界上下文，其实是一个动态的过程、演进的过程。从团队合作层面看待限界上下文，就从技术范畴上升到了管理范畴一个高效的团队需要满足两点要求:1 共同的目标2 团队的边界设计团队组织时确定工作边界的原则...

原创 识别限界上下文

从业务边界识别限界上下文领域驱动设计围绕着“领域”来开展软件设计。：1 明确了系统的问题域和业务期望2 梳理出主要的业务流程，这些业务流程体现了各种参与者在这个过程中通过业务活动共同协作，最终完成具有业务价值的领域功能。参与角色（Who）、业务活动（What）和业务价值（Why）3 抽象出不同的业务场景，这些业务场景又由多个业务活动组成，我们可以利用前面提到的领域场景分析方法（用例...

原创 限界上下文的控制力

限界上下文目的：不在于如何划分边界 而在于如何控制边界对于统一语言：限界上下文是语言的边界对于领域模型：限界上下文是模型的边界语言的边界以及模型的边界可以 界定问题域对于系统架构：限界上下文确定了应用边界和技术边界限界上下文 分离了业务边界目的：约束不同上下文的领域模型例如 电商中的产品：1 采购上下文：关注产品...

原创 限界上下文

限界上下文的含义：用一个清晰可见的边界（Bounded）将这个上下文（Context）勾勒出来Context 表现了业务流程的场景片段上下文（Context）其实是动态的业务流程被边界（Bounded）静态切分的产物。上下文（Context）是业务目标，限界（Bounded）则是保护和隔离上下文的边界，避免业务目标的不单一而带来的混乱与概念的不一致。限界上下...

原创 统一语言

统一语言定义：需求分析的过程（系统目标、范围、具体功能达成一致的过程）中提炼领域知识的产出物意义：在统一语言的前提下可以寻找正确的领域概念，为建立领域模型提供重要参考。 消除领域专家与团队、以及团队成员之间沟通的分歧与误解统一语言的体现：1 统一的领域术语2 领域行为描述统一的领域术语：在两个不同的语言世界中进行正确翻译的过程（如 开发人员与领域专家之间，他...

原创 领域场景分析提炼领域知识

组成场景的要素：6W模型：Who：用户、What：业务功能、Why： 业务价值、Where：domain、When：应用层对domain层调用的时序、How：业务实现领域场景分析前提：识别参与该场景的用户角色（WHO）业务功能（What）：分析该用户 特征属性 辨别其在在整个场景中参与的活动（如订单系统 用户只参与了下单）...

原创 DDD对软件复杂度的应对

表象：规模与结构 导致 理解力障碍变化 导致 预测能力问题根因：需求DDD关注的焦点 在于 领域 以及 领域逻辑原因： 软件系统的本质： 给客户提供具有业务价值的领域功能需求分为业务需求：业务复杂度技术需求：技术复杂度面对一个相对复杂的软件系统时，面临的问题： 问题域过于庞大而复杂，使得从问题域中寻求解决方案的挑战增加，该...

原创 控制软件复杂度的原则

导致软件系统变得复杂的成因是规模、结构与变化三要素控制复杂度的原则：就需要对 规模、结构与变化 逐个击破规模保证系统的小规模，分而治之，小即是美在应对新需求时，不会直接去修改一个复杂的旧系统，而是通过添加新特性，然后对这些特性进行组合。要满足小程序之间的自由组合，就需要满足第二条原则，即每个程序的输入和输出都是统一的，因而形成一个统一接口（Uniform...

原创 DDD与软件复杂度

DDD解决的是 软件开发的复杂度问题 只有应用在大型项目上才能产生最大的收益DDD 可以应对以下问题： 没有对行为的重用，也没有对业务问题的抽象，每当操作用到业务规则时，都要重复这些业务规则。 快速的原型建立和迭代很快会达到其极限，因为抽象的缺乏限制了重构的选择。 复杂的功能很快会让你无所适从，所以程序的扩展只能是增加简单的应用模块，没有很好的办法来实现更丰富的...

原创 DDD基础

是什么：领域驱动设计是一种方法论：是针对软件开发领域提出的一套系统与理论分析方法 是一种思维方式，也是一组优先任务目的：降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。 加速那些必须处理复杂领域的软件项目的开发方法：1 将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为2 合理运用面向对象的封装、继承和多态等设计要素...

原创 内部类

什么是 内部类 外部类？外部类：只能定义一个类名与文件名完全 致的公开类，使用public class 关键字来修饰。内部类：任何一个类都可以在内部定义另外一个或多个类内部类本身就是 类的一个属性属性字段 private static String str由访问控制符、是否静态、类型、变量名内部类 private static class Inner{}，...

原创 类内方法

除构造方法外，类中还可以有三类方法实例方法、.class 字节码文件加载之后，实例方法并不会被分配方法人口地址 ， 只有在对象创建之后才会被分配方法人口地址实例方法可以调用静态变量和静态方法 应尽量使用 类名名.静态方法”来调用静态方法：类方法( 1 )静态为法中不能使用实例成员变量和实例方法。( 2 )静态为法不能使用 super 和 this 关键字 ， 这两个关键...

原创 封装 继承 多态 抽象 拷贝

面向对象“四大特性 ” ：封装、继承、多态、“抽象 ”封装功能内聚 降低耦合度以什么样的方式暴露哪些信息对属性、数据、部分内部敏感行为实现隐藏设计模式七大原则之一的迪米特法则就是对于封装的具体要求，即 A 模块使用B 模块的某个接口行为，对 B 模块中除此行为之外的其他信息知道得尽可能少。在不知道什么样的访问控制权限合适的时候，优先推荐使用 private控制...

原创 Class

类的定义由访问级别、public和无访问控制符类型、class、 interface、 enum类名、是否抽象、是否静态、泛型标识、继承或实现关键字、父类或接口名称等组成。类的组成：成员和方法成员变量、public protect private 方法 getset方法定义类的过程就是抽象和封装的过程接口与抽象类则是对实体类进...

转载 ScheduledThreadPoolExecutor JDK定时任务线程池

https://www.jianshu.com/p/18f4c95aca24流程：1 提交任务的时候，任务被包装成ScheduledFutureTask对象加入延迟队列并启动一个woker线程。2 用户提交的任务加入延迟队列时，会按照执行时间进行排列，也就是说队列头的任务是需要最早执行的。而woker线程会从延迟队列中获取任务，如果已经到了任务的执行时间，则开始执行。否则阻塞等待剩余延...

原创 线程池

线程池原理：每一个 Thread 的类都有一个 start 方法。 当调用start启动线程时Java虚拟机会调用该类的 run 方法。 那么该类的 run() 方法中就是调用了 Runnable 对象的 run() 方法。我们可以继承重写 Thread 类，在其 start 方法中添加不断循环调用传递过来的 Runnable 对象。这就是线程池的实 现原理。循环方法中不断获取 Run...