守株阁

何时加载类 根据 Java 语言规范（JLS §12.4），类或接口在首次主动使用时才会被初始化。主动使用包括以下情况： 遇到 new、getstatic、putstatic、invokestatic 等字节码指令时。这些指令分别对应创建对象实例、读取或设置静态字段、调用静态方法。 对类进行反射调用时，如 Class.forName() 或 Method.invoke()。 初始化某个类的子类时，父类会先被初始化（但父类接口不会）。 虚拟机启动时会先加载设置的主类，即包含 main() 方法的类。 使用 java.lang.invoke 包的动态语言支持特性时，如 MethodHandle 调用。 需要注意的是，被动引用（如通过数组引用、常量引用、访问子类的静态字段等）不会触发类初始化。 从 Java 到 cpp 源码分析 双亲委派模型的工作流程 双亲委派模型的核心逻辑在 java.lang.ClassLoader.loadClass(String name, boolean resolve) 方法中： 123456789101112131415161718192021222...

数据的分类 状态型数据，需要三地五中心容灾，需要强一致性，事务延迟较高。对状态型数据的操作实际上是对同一行记录进行反复操作。 流水型数据，对历史数据依赖较少，每一笔业务相对独立。 基于一定的业务理解和假设，我们可以设计出一套新的模型和存储方案，实现流水型 FO。 部署形态 通常流水型 FO 要求部署三套库。 主库 LFO 库 同城 FO。承担机房级故障。 RFO 库，异地 FO 库。承担区域 数据格式 8 位日期 + 1 位数据版本 + 1 位系统版本 + 3 位系统标识 + 2 位预留 + 2 位 uid + 2 位弹性位 + 8 位 sequence 设计数据格式影响几个问题： 1 当系统发生一笔流水的时候，流水应该落到哪个库里去。 2 当我需要一笔流水时，我应该从哪个库里面查询这笔流水。 有关联关系的单据，如果发生弹性切换，要保证正逆向流程的单据都弹到一个库里。 流水型 FO 方案如何做到业务无感知？ ？？？ 流水型 FO 发生强切的时候如何保证业务业务无损？ ？？？

能力要素 要重点建设的三种能力： 结构化的思维 结构化的工作模式 结构化的能力建设 什么是结构化 structured：建立中心（问题、目标）以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制定行动计划。 同理，按照逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳归总成一个中心，也是结构化。 案例 建立结构化的中心 一个业务需求，通常可以按照两个维度分解为不同的子结构： 1 当前业务需求的目标是什么？（事的维度）。 目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线。 目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案。 2 为什么需要我来做？（人的维度） 是因为我工作量还有 buffer 所有承担这部分：目标人的维度是完成职能范畴内的工作。 是因为我在这方面技术比较擅长：目标人的维度是利用事情强化自身能力和使用能力把事儿做好。 沿中心上行 对单个业务需求而言，从事、人两个维度建立起的中心即其核心，是最主要部分，建立一颗结构...

Java 进程的 OOM 跨两层：Linux 内核的 OOM Killer 在物理内存或 cgroup limit 触及时 kill 进程，事后只能从 dmesg 还原；JVM 的 OutOfMemoryError 在堆/元空间/直接内存耗尽时抛异常，常带堆栈和 dump。两层工具栈不同：Linux 侧看 dmesg、cgroup、内核参数，JVM 侧看 jstat、jmap、jstack、arthas、JFR、gperftools。 一、Linux 层：OOM Killer 机制 Linux 内核有个 OOM (Out of Memory) Killer 的机制，可以在系统内存不足的时候，通过主动杀死一些进程来释放更多的内存空间。 很多时候，可以 ping 通一台服务器，但无法 ssh 上去，因为 sshd 被 OOM Killer 杀掉了。ping 能 ping 通，是因为处在内核态协议栈还能工作，发出回送报文。sshd 则因为是用户态进程，直接被干掉了。 OOM Killer 工作流程 OOM Killer 的完整工作流程如下： 关键机制 oom_score 每个进程都有...

遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求： 限流保护。抵挡来自突发流量冲垮整个集群。 降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。 削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。 这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。 以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设： 发现机制，是我们的眼睛，也是基础。 监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。 主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。 快速恢复 根据监控快速寻找问题发生的方向和位置。 找对恢复的人、恢复的预案。 倾向于选择成本低的恢复手段。---- 并不是所有的恢复都用大招（熔断、限流），大招...

1 用户需求场景分析，识别业务全景 use case。这一个阶段重点识别 actor 和 use case。 2 分析模型鲁棒图，识别出业务场景中所有的实体对象。识别边界类（类似 ui）、控制类（类似 controller）和实体类（类似model）三种类型。 3 领域划分，将所有识别出的实体对象进行分类。 比如，主订单、子订单对象和归类到交易域；买家、卖家对象可以归类到会员域。 当然，最终所有的对象是归类到十个域还是二十个域，从理论上看，可以看做一次排列组合过程。只是，我们往往可以根据以往的经验、业务知识，做一个初始的域划分（但不见得是靠谱的）。因此，我们可以认为一个域实际上是一个或多个实体对象的信息集合，并对所管理的实体对象的生命周期进行管理。 4 评估域划分合理性，并进行优化。域划分并一定总是能得到唯一的答案，但可以得到最好的答案。评价一个域划分方案是不是足够好，其实是要根据“高内聚、低耦合”的原则进行评分。这一步就要画时序图了。 时序图的泳道，应该先设计到域颗粒度。可以看到域之间的交互，也就可以看到域之间的交互的复杂度。在绘制过程中，我们可以看域与域之间的调用是否过于频繁...

https://stackoverflow.com/questions/18618779/differences-between-proxy-and-decorator-pattern https://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. Relationship between a Proxy and the real subject is typically set at compile time, Proxy instantiates it in some way, whereas Decorator is assigned to the subjec...

软件设计，必有单元/片段，不管他们叫做系统、层次、模块、类型和方法，都是为了在一个抽象颗粒度上分割复杂度，让我们降低思考的难度，并且进行团队协作。 我们在进行系统交互的时候，要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性，拥抱间接性。 间接性的实现，就是契约、接口或者门面/桥接模式。这些实践的使用，可以轻易让我们切换层次之间的实现，而使变动不扩散出去。

字符类或者字符集 字符组（character classes） 字符集（character sets） 元字符 metacharacters [abc] A single character of: a, b or c [^abc] Any single character except: a, b, or c [a-z] Any single character in the range a-z [a-zA-Z] Any single character in the range a-z or A-Z ^ Start of line $ End of line 开头结尾：^$，正好对应键盘上的64。 \A Start of string \z End of string . Any single character \s Any whitespace character \S Any non-whitespace character \d Any digit \D Any non-digit \w Any word characte...

同比比较微观，环比比较宏观。 摘自百度： 同比，是指在相邻时段中的某一相同时间点进行比较； 13年和14年是相邻时段，13年3月和14年3月是这两个相邻时段的同一个时间点，都是3月，这两个时段进行数据对比，就是同比； 环比，则相对更简单，就是相邻时间段的对比，不象同比那样，是在相邻时间段内部的某个相同时间点的对比； 14年4月和14年3月是相邻时间段，这两个时间段的数据都比，就是环比；