近一个月，闭关开发了一个面向海外的项目，合作的对象是斯坦福和麻省理工的博士，很荣幸能够和这些全球顶尖大学毕业的大牛合作，今天，趁着周末总结下自己的一些感受。

1. 英语是硬伤

因为项目是面向海外，整个合作全程是英语，这就一览无遗地暴露出自己的英文短板，特别是口语，在技术评审过程和讨论中，自己捉襟见肘的英文，只能不断的通过技术流程图和文字来弥补口语表达的不足。

最开始合作时比较羞涩，毕竟知道自己的英语有几斤几两，后面慢慢的放开，把自己的英语老本和盘托出，不过这也坚定了自己加强英文的决心，毕竟做程序开发，英语功底直接决定你理解英文资料的速度和程度。

2. 编程语言要多样

我自己最常用的是 java，但这次项目开发的主要语言是python，另外还涉及到C/C++, java, nodejs。尽管python，C/C++都有所了解，但是，要像 Java一样轻松驾驭去开发这么庞大的工程还是有点吃力。而在合作的过程中，发现他们语言的全能性，python，Java，C++，前端语言，他们都可以平滑切换，绝对的全栈工程师。

这个或许跟每个国家IT环境不一样有很大的关系，但是，作为 Java程序员，我个人还是比较建议再掌握一门动态语言，首选是python，像目前比较主流的数据分析、机器学习、科学计算、自动化和游戏开发等，Python绝对功不可没。另外，通过两种语言的对比，你能更好的看清每种语言的优点和不足，在日常开发中，或许就能借鉴另外一种语言的优点。

3. CR的重要性

CR，就是我们常说的Code Review（代码审查）。在国内的公司工作了这么多年，会做 CR的公司很少，包括一线大厂，能严格执行 CR的更是微乎其微，很多人说是因为业务太多，没有时间做CR，但是，究其原因是国内没有 CR的基因，技术管理者不推动，底层开发人员借着业务繁忙的理由，所以 CR就形同虚设。

下面给了几张项目CR的截图，因为涉及到商业隐私，所以部分信息被打码了：

图一：对于错误的实现，CR 会指正和给出正解。

图二：展示了 CR 甚至细化到了Doc文档级别。

图三：展示了 CR 过程中的探讨，给出自己意见的同时也征询组员更多的idea

CR看似很费时，反反复复的修改和讨论，但是，它和技术方案的讨论不一样，CR针对的是技术方案已经成型的代码实现，所以这个过程更能体现出不同技术人员对同一个技术方案的的思考和实现方式，对于整个项目的质量有大大的提高，另外对于开发者之间的磨合是一个很好的润滑剂。

4. 包容

越优秀的人越懂得包容。这句话放到这个项目上最合适，一个是对于我英语水平的包容。一个是对我 Python 掌握程度的包容。通过上面部分 CR截图也能体现出来。有了这些包容，让我可以更快，更有信心的融入到项目开发。

5. 较真

对于代码实现，技术方案的较真，通过上面的 CR截图也可以体现，他们对于代码的较真可以小到一个Doc文档和标点符号，以及代码的格式化，对于代码性能可以通过大量的技术测试和对比，甚至这块代码不是他们负责的，这个或许就是我们说的技术洁癖和极客精神。

依然记得几年前的一个技术峰会上，某大牛说：中国的码农千千万万，如何让你的代码有亮点，那就是不断的抠细节，大到技术架构，小到标点符号，然后不断的重构，重构。

总结

1. 通过这个项目，让我有幸见识了从 Google，AWS出来的优秀程序员的编码习惯。
2. 学英语绝对不是崇洋媚外，它在一定程度上绝对了程序员的技术高度和深度，可以观察你身边优秀的技术人员，英语是不是都不差。
3. 一定要向优秀的人靠近，和他们一起写代码，勇敢的让他们帮你CR，在交流和讨论中获取更多的葵花宝典；
4. 程序员是一个终身学习的职业，一定要持续学习；

大家好，我是伍六七。

干程序员的都会碰到各种各样的 bug，有的 bug 我们看一眼、或者多看几眼就能看出来问题。

但是，也有很多问题，我们看不出来，这个时候，我们不妨把我们的代码扔给 GPT，看看它能不能帮我们找到 bug，Fix the bug！

我们来看个例子：

阿七来到这个公司之前，一直在传统 IT 公司工作，从来没用过什么分布式锁、多线程等高端技术。

这次，有一个业务场景，需要使用分布式锁解决问题。阿七按照自己的了解，写了一个分布式锁，结果死活有问题。

看了半天，头都挠凸了，就是不知道怎么回事，这个时候，他想到了大模型，他把问题扔给了 GPT。

prompt：

long currentTimeMillis = System.currentTimeMillis();
final String sequenceId = UUID.randomUUID().toString();
redisLockService.lock(username + currentTimeMillis, sequenceId, 2, TimeUnit.SECONDS);
---
请你分析上面的Java代码，如果有bug，请指出来，并给出正确写法

大模型返回：

这段代码的目的是使用 Redis 锁来对某个资源进行加锁操作。下面是对代码的分析：

1. 
   

   获取当前时间的毫秒数，存储在 currentTimeMillis 变量中。

   
   


2. 
   

   生成一个随机的 UUID 字符串，存储在 sequenceId 变量中。

   
   


3. 
   

   调用 redisLockService.lock 方法，传入参数 username + currentTimeMillis、sequenceId、2 和 TimeUnit.SECONDS，对资源进行加锁操作。

   
   

如果存在 bug，可能是以下几个方面：

1. 
   

   username 变量的值是否正确，确保它是唯一的且能够标识资源的唯一性。

   
   


2. 
   

   redisLockService.lock 方法的实现是否正确，确保它能够正确地加锁并设置过期时间。

   
   


3. 
   

   锁的释放是否在适当的时机进行，以避免资源被长时间锁定。

   
   

正确的写法可能如下所示：

long currentTimeMillis = System.currentTimeMillis();

final String sequenceId = UUID.randomUUID().toString();

String lockKey = username + currentTimeMillis;

boolean lockAcquired = redisLockService.lock(lockKey, sequenceId, 2, TimeUnit.SECONDS);

try {

    if (lockAcquired) {

        // 执行需要加锁的操作

    } else {

        // 锁未获取到，处理相应逻辑

    }

} finally {

    if (lockAcquired) {

        redisLockService.unlock(lockKey, sequenceId);

    }

}

在正确的写法中，我们首先获取锁，并在获取到锁的情况下执行需要加锁的操作。然后，在 finally 块中，我们释放锁，确保无论是否成功获取到锁，都能够正确释放资源。

一顿瞎扯，就是没找到最严重的那个 bug，我们继续问它。

prompt：

你没有找到这段代码的最严重的 bug，请你再深入分析分析，找到代码中的严重 bug

大模型返回：

非常抱歉，我之前的回答有误。这段代码存在一个严重的 bug，即在分布式环境下，由于锁的 key 值不唯一，可能会导致锁的误解锁或者锁的覆盖，从而导致并发问题。

正确的写法应该是使用 username 和 sequenceId 作为锁的 key 值，以确保锁的唯一性。修改后的代码如下：

long currentTimeMillis = System.currentTimeMillis();

final String sequenceId = UUID.randomUUID().toString();

String lockKey = username + "_" + sequenceId;

redisLockService.lock(lockKey, sequenceId, 2, TimeUnit.SECONDS);

try {

    // 执行需要加锁的操作

} finally {

    redisLockService.unlock(lockKey, sequenceId);

}

在正确的写法中，我们使用 username 和 sequenceId 作为锁的 key 值，以确保锁的唯一性。同时，在 finally 块中，我们释放锁，确保无论是否成功获取到锁，都能够正确释放资源。

这次，我们发现，它找到了代码中最严重的 bug，但是它给出的代码依然没有解决这个 bug，我们继续问它。

prompt；

lockKey 还是没有保证唯一性，并不能解决分布式锁资源不唯一的问题。请你深入思考，再给出正确的设置 lockKey 的代码.

大模型返回：

非常抱歉之前的回答仍然有误。你是正确的，lockKey 的生成方式仍然存在问题，无法保证在分布式环境下的唯一性。

为了确保锁的唯一性，可以使用 Redis 的分布式锁实现方式，例如使用 Redisson 或者 RedLock 等库来实现分布式锁。这些库提供了可靠的分布式锁实现，可以确保在分布式环境下的唯一性和正确性。

下面是使用 Redisson 实现分布式锁的示例代码：

long currentTimeMillis = System.currentTimeMillis();

final String lockKey = "lock:" + username; // 使用固定的前缀加上 username 作为锁的唯一标识

final String sequenceId = UUID.randomUUID().toString();

RLock lock = redissonClient.getLock(lockKey);

boolean lockAcquired = false;

try {

    lockAcquired = lock.tryLock(2, TimeUnit.SECONDS);

    if (lockAcquired) {

        // 执行需要加锁的操作

    } else {

        // 锁未获取到，处理相应逻辑

    }

} finally {

    if (lockAcquired) {

        lock.unlock();

    }

}

在上述代码中，我们使用 Redisson 提供的 RLock 接口来获取分布式锁。通过调用 tryLock 方法来尝试获取锁，设置超时时间为 2 秒。如果成功获取到锁，则执行需要加锁的操作；否则，处理相应的逻辑。在 finally 块中，我们根据是否成功获取到锁来决定是否释放锁。

请确保你已经正确地引入了 Redisson 依赖，并且配置了正确的 Redis 连接信息。

这次，它成功的理解了我们的意思，并且修改了代码，解决了分布式锁资源 key 不唯一的问题。

关注我，送你全套我整理的 Java 岗位面试资料。这是我自己之前整理的面试题，靠着这份面试题，我从 30 人的小公司，进了 2000 人+的央企子公司，之后又进了互联网大厂。

如果有人问你什么是策略模式？你可以尝试这样回答

策略模式是一种行为设计模式，它允许在运行时根据不同的情况选择不同的算法策略。这种模式将算法的定义与使用的代码分离开来，使得代码更加可读、可维护和可扩展。

在策略模式中，通常有一个抽象的策略接口，定义了一系列可以被不同策略实现类所实现的方法。在使用时，可以根据需要选择合适的具体策略类，并通过接口进行调用。

虽然解释了策略模式，但是面试官可能会认为你在吊书袋，完全没有自己的理解。我因为被领导卷到了，所以对策略模式有一些其他的理解，接下来我从业务中台实际遇到的问题出发，谈谈怎么被领导卷到，谈谈我对策略模式的优化和理解。

在业务中台，可以根据具体情况选择合适的策略类来执行相应的业务逻辑，从而满足不同业务方的要求。

由于各个业务方的业务逻辑存在差异性和相似性，编写中台代码时需要考虑这些差异性，并预留扩展点以供不同业务方根据自身需求提供策略类。在这种情况下，可以应用策略模式。

当业务方有特殊的业务逻辑时，只需要添加新的策略实现类即可，不需要修改现有的代码，方便了后续的维护和扩展。

然而在我们在应用策略模式时遇到了几个问题

遇到的实际问题

由于业务中台逻辑非常复杂，每个业务线的业务场景都很难保证完全一样，在代码实践中我们的系统出现了非常庞大复杂的策略类，将大量业务逻辑整合到同一个策略中，这导致系统能力复用非常困难。

举个例子，在退款校验逻辑中 业务场景 A，（售卖红包，类似于美团饿了么会员）。 需要判断如下校验逻辑，如果命中，则不允许退款！

1. 
   

   订单是否在生效期，过期不允许退

   
   


2. 
   

   订单是否在已使用，已使用不可退

   
   


3. 
   

   订单如果是某类特殊商品订单，则不可退

   
   


4. 
   

   如果超过当天最大退款次数，则不可退。

   
   

于是我们在编写代码时，就新定义 ConcreteStrategyA ，将以上 4 个业务逻辑放到策略类中。

过一段时间，又出现了业务场景 B（售卖红包，类似于美团饿了么会员）。它的校验逻辑和A 大同小异

1. 
   

   订单是否在生效期，过期不允许退

   
   


2. 
   

   订单售卖的红包完全使用不可退，部分使用可以退。

   
   


3. 
   

   如果超过当天最大退款次数，则不可退。

   
   

业务场景B 相比A 而言，少校验了 “特殊商品订单不可退”的逻辑，同时增加了部分使用可以退的逻辑。

如何设计代码实现两种业务场景的校验逻辑呢？ 这是非常具体的问题，如果是你如何实现呢？

完全独立的策略类

我们在最开始写代码时，分别独立实现了 ConcreteStrategyA、ConcreteStrategyB。两者的校验逻辑各自独立，没有代码复用。

此时的系统类图如下

这种实现方式是大量的代码拷贝，例如退款次数限制、生效期校验等代码都大量重复拷贝了。

后来我们发现了这个问题，将相关校验方法抽到父类中。

继承共同的父类

为了更好的复用校验策略，我们将校验生效期的方法、校验退款次数的方法抽取到共同的父级策略类。由具体的子策略类继承BaseStrategy 父策略类，在校验逻辑中，使用父级的校验方法。

如下图的类图所示

在相当长的一段时间里，我们认为这已经是最优的实现方式了。

但是被领导卷到了！

被卷到了

“新增业务场景时，为什么校验逻辑都是复用的原有能力，还需要新增扩展类，还需要开发代码呢？” 领导这样问道。

我尝试回答领导的问题：“开发这段代码，并不算太难，只需要增加一个扩展类就可以了！”

“你数数现在有多少个扩展类了？” 领导似乎有些生气，

我一看扩展类的数量，被吓到了，已经有了15个扩展类。这一刻真的非常尴尬，平时领导从不亲自看代码。估计是突然心血来潮。从表情来看，他好像很生气，估计是代码没看懂！

“我看到这部分代码时，想要查看具体的策略类，但Idea直接刷出了15个策略类……为什么会有这么多的扩展类呢？” 领导进一步补充道。

场面僵住了，我也没什么好办法……。当然领导向来的传统是：只提问题，不给解决办法！ 我只能自己想解决办法！如何解决策略类过多、扩展类膨胀的问题呢？

策略类过多怎么办！

当业务场景非常多，业务逻辑非常复杂时，确实会出现非常多的策略类。但领导的问题是，现有业务场景有很多相似性，某些新增业务场景和原有业务场景类似，校验逻辑也是类似的，为什么还需要新增扩展类呢？

经过深思熟虑，让我发现问题所在！

策略类粒度太粗，导致系统复用难

目前我们的系统设计是每个业务场景都有单独的策略，这是大多数人认可的做法。不同的业务场景需要不同的策略。

然而，仔细思考一下我们会发现，不同业务场景的退款校验逻辑实际上是由一系列细分校验逻辑组合而成的，退款校验逻辑在不同的业务场景中是可以被重复使用的。

为什么不能将这些细分退款校验逻辑抽象为策略呢？例如，将过期不允许退款、已生效不可退款、超过最大退款次数不允许退款等校验逻辑抽象成为校验策略类。

各个业务场景组合多个校验策略，这样新增业务场景时，只需要组合多个校验策略即可。

如何组合校验策略

首先需要抽象校验策略接口： VerifyStrategy

classDiagram

class VerifyStrategy{

+void verify(VerifyContext context);

}

然后定义 VerifyScene 类

classDiagram

class VerifyScene{

+ Biz biz;

+ List<VerifyStrategy> strategies;

}

如何把对应具体策略类配置到VerifyScene中呢？本着 ”能不开发代码，就不要开发代码，优先使用配置！“的原则，我们选择使用Spring XML 文件配置。（在业务中台优先使用配置而非硬编码，否则这个问题不好回答。“业务方和中台都需要开发，为啥走你中台？”）

使用Spring XML 组合校验策略

在Spring XML文件中，可以声明VerifyScene类的Bean，初始化属性时，可以引用相关的校验策略。

 <bean name="Biz_A_Strategy" p:biz="A" class="com.XX.VerifyScene">

        <property name="strategies">

            <list>

                <ref bean="checkPeriodVerifyStrategy"/> <!--校验是否未过期-->

                <ref bean="checkUsageInfoVerifyStrategy"/> <!--校验使用情况-->

                <ref bean="checkRefundTimeVerifyStrategy"/><!--校验退款次数-->

            </list>

        </property>

    </bean>

当需要新增业务场景时，首先需要评估现有的校验策略是否满足需求，不满足则新增策略。最终在XML文档中增加 VerifyScene 校验场景，引用相关的策略类。

这样新增业务场景时，只要校验逻辑是复用的，就无需新增扩展类，也无需开发代码，只需要在XML中配置策略组合即可。

在XML文档中可以添加注释，说明当前业务场景每一个校验单元的业务逻辑。在某种程度上，这个XML文档就是所有业务的退款校验的业务文档。甚至无需再写文档说明每个业务场景的退款策略如何如何~

和领导汇报以后，领导很是满意。对业务方开始宣称，我们的中台系统支持零开发，配置化接入退款能力。

结束了吗？没有 ，我们后来想到更加优雅的方式。

使用Spring Configuration 和 Lamada

Spring 提供了@Bean注解注入Bean，我们可以使用Spring @Bean方式声明校验策略类

@Bean

public VerifyStrategy checkPeriodVerifyStrategy(){

   return (context)->{

        //校验生效期

   };

}

通过以上方式，可以把checkPeriodVerifyStrategy 校验策略注入到Spring中，spring beanName就是方法名checkPeriodVerifyStrategy。

在Spring XML中可以使用 <ref bean="checkPeriodVerifyStrategy"/> 引用这个bean。

并且当点击XML中beanName时，可以直接跳转到 被@Bean修饰的checkPeriodVerifyStrategy方法。这样在梳理校验流程时，可以很方便地查看代码

点击这个BeanName，会跳转到对应的方法。（付费版Idea支持，社区版 Idea 不支持这个特性）

总结

总结几个问题

1. 
   

   策略模式目的是：根据不同的业务场景选择不同的策略来执行相应的逻辑

   
   


2. 
   

   策略模式一定要进行细化，通过组合多个细分策略模式为一个更大的策略，避免使用继承方案。

   
   


3. 
   

   使用Spring XML 组合多个策略模式，可以避免开发。减少新增策略类

   
   


4. 
   

   使用Spring Configuration @Bean 将策略类注入Spring 更加优雅

   
   

感谢你阅读本文

今天我们来分享一下怎么怎么写好一个方法，我记得大四的时候彪哥推荐我去读《代码精进之路，从码农到工匠》这本书，那时候由于项目经验不多，所以对于书中很多东西没有感同身受，所以不以为然。

后面做的项目越来越多，从痛苦中不断思考，也看了一些优秀开源框架的实现，逐渐对于开始理解书中的思想。

下文只列举了书中的的“方法封装”，“参数”和“方法短小”这三个，其他的没有列举，因为我觉得其实只要这三点我们执行到位，写出来的代码虽然谈不上优秀，但是维护性和可读性一定会大大提高。

封装的艺术

我们在学习面向对象编程时就知道面向对象的几大特征是抽象，继承，封装，多态，所以学会合理的封装是一件很重要的事情，这也是我们每个程序员应该有的意识。

判断封装

在方法中，总是难免会有很多判断，判断越多，程序就会变得越复杂，但是又不能不判断，我们可以使用设计模式来改善判断很多的方法，使用设计模式来优化判断，比如策略模式，但是其实它并没有消除判断，换句话说，判断是消除不了，我们能做的只能是让判断的代码可读，下面我们来看一段代码。

如下是一个判断，对文件小于1G，类型为txt，文件名中包含user_click_data或者super_user_click_data的文件可以进行处理

对于这个判断，虽然条件并不复杂，但是在代码中就显得“不清洁”，特别是随着系统的不断迭代，加入的人员不断增多，那么判断将会越来越多，如果开发人员加上清晰的注释，那么就比较容易读懂，但是并不是谁都有这样的习惯。

之前我遇到的代码中，有些一个方法中四五十个判断，而且判断还特别复杂，各种&&，||等一大堆，读起来十分费劲，对于这样的代码，遇到真的会让人抓狂。

如何解决呢？

封装判断就是一个好的方案，上面的判断代码我们就可以进行封装，如下。

上面我判断我们将其抽出来作为一个单独的方法，在加上可理解的方法名，那么别人在读你代码的时候就很容易读懂，也保证了代码的清洁，当然，方法命名是一件很难的事情，不过如果命名得不够准确，我们可以加上清晰的注释来解决。

虽然上面这段代码看似没啥改变，但是随着系统的不断复杂，就能体现出它的作用了，我经常看到别人在主流程的代码中加入很多复杂的判断，在我刚开始写代码的时候，也做过这种事，很多时候如果注释不清，命名不规范，上下文不清晰，那么读起来就很痛苦，而且整个方法看起来让人特别难受。

所以，一个看似很小的改动，却能在时间的作用下显得如此重要，保持这样一个习惯，不仅是对自己负责，也是对他人负责。

参数问题

参数问题也是我们应该去考虑的问题，当在一个方法中，如果参数特别多是很不友好的，我之前碰到过一个方法有十五六个参数，首先这么多个参数，在传递的时候，如果使用对IDEA使用比较熟悉，那么可以使用快捷键查看下一个参数是什么类型，如果使用不熟悉，那么就需要点进方法中去看，这是一个体力活。

加上参数越多，维护成本就越高，比如我需要加一个参数，但是这个参数并不是必须的，有些方法用到，有些不用，但是由于使用的是同一个方法，所以调用这个方法的地方都需要加上这个参数，调用的地方越多，成本就越大，如果是一个RPC接口，修改的成本更大。

复杂的参数封装成类。

对于复杂的参数，推荐封装成类然后进行传递，在添加或者减少字段的时候是在类中进行，没有对形参进行增加或者减少，对调用此方法的地方基本没任何影响，我们只需要在需要添加或者减少这个参数的地方进行操作，不需要的地方就保持不动。

方法尽量保持短小

方法短小更容易让人阅读和维护，当我去阅读别人的代码的时候，有些类有七八千行代码，一个方法有五六百行代码的时候，其实内心是奔溃的！

当然，在我刚开始写代码的时候，我也不懂，所以一个方法从来不去优化，也是一个方法一口气干到底，我记得当时给老师做一个项目，一个类我在Controller层直接写了几百行，Service层都不用，还有写Vue，也不会去使用组件和封装函数，所以一个Vue文件几千行，当需要修改的时候，十分麻烦，找一个方法和变量也特别费力。

记得上一个星期，我和前端同事联调，我看他去找一个方法找了足足三四分钟，因为项目十分庞大，加上设计有很大的缺陷，我看他们一个VUE文件可达到八九千行，所以才出现这个问题。

其实无论对于前端还是后端，Java还是golang等等，代码的短小都比较容易去阅读和维护，如果发现方法越写越大，那我们就要考虑去提取，去拆分了，《代码精进之路》作者推荐Java一个方法不要超过20行，不过也不是绝对的。

对于像Spring这种特别复杂的框架，因为不断升级和迭代，所以有些方法也变得特别长，代码也变得可读性不那个高，但是也不影响它是Java生态中使用最广泛，最强大的框架。

只不过对于我们普通人来说，因为水平肯定没有Spring团队的强，所以保证方法的可读性是十分重要的。

今天的分享就到这里，感谢你的观看，我们下期见。

参考：《代码精进之路，从码农到工匠》weread.qq.com/web/reader/…?

工作六年，看到这样的代码，内心五味杂陈......

那天下午，看到了令我终生难忘的代码，那一刻破防了......

🔊 本文记录那些年的 Java 代码轶事

ヾ(•ω•`)🫥 故事还得从半年前数据隔离的那个事情说起......

📖一、历史背景

1.1 数据隔离

预发，灰度，线上环境共用一个数据库。每一张表有一个 env 字段，环境不同值不同。特别说明： env 字段即环境字段。如下图所示：

1.2 隔离之前

🖌️插曲：一开始只有 1 个核心表有 env 字段，其他表均无该字段；
有一天预发环境的操作影响到客户线上的数据。 为了彻底隔离，剩余的二十几个表均要添加上环境隔离字段。

当时二十几张表已经大量生产数据，隔离需要做好兼容过渡，保障数据安全。

1.3 隔离改造

其他表历史数据很难做区分，于是新增加的字段 env 初始化 all ，表示预发线上都能访问。以此达到历史数据的兼容。

每一个环境都有一个自己独立标志；从 application.properties 中读该字段；最终到数据库执行的语句如下：

SELECT XXX FROM tableName WHERE env = ${环境字段值} and ${condition}

1.4 隔离方案

最拉胯的做法：每一张表涉及到的 DO、Mapper、XML等挨个添加 env 字段。但我指定不能这么干！！！

具体方案：自定义 mybatis 拦截器进行统一处理。 通过这个方案可以解决以下几个问题：

• 业务代码不用修改，包括 DO、Mapper、XML等。只修改 mybatis 拦截的逻辑。


• 挨个添加补充字段，工程量很多，出错概率极高


• 后续扩展容易

1.5 最终落地

在 mybatis 拦截器中， 通过改写 SQL。新增时填充环境字段值，查询时添加环境字段条件。真正实现改一处即可。 考虑历史数据过渡，将 env = ${当前环境}
修改成 en 'all')

SELECT xxx FROM ${tableName} WHERE env in (${当前环境},'all') AND ${其他条件}

具体实现逻辑如下图所示：

1. 其中 env 字段是从 application.properties 配置获取，全局唯一，只要环境不同，env 值不同


2. 借助 JSqlParser 开源工具，改写 sql 语句，修改重新填充、查询拼接条件即可。链接JSQLParser

思路：自定义拦截器，填充环境参数，修改 sql 语句，下面是部分代码示例：

@Intercepts(

        {@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class})}

)

@Component

public class EnvIsolationInterceptor implements Interceptor {

    ......

    @Override

    public Object intercept(Invocation invocation) throws Throwable {

        ......

        if (SqlCommandType.INSERT == sqlCommandType) {

            try {

                // 重新 sql 执行语句，填充环境参数等

                insertMethodProcess(invocation, boundSql);

            } catch (Exception exception) {

                log.error("parser insert sql exception, boundSql is:" + JSON.toJSONString(boundSql), exception);

                throw exception;

            }

        }



        return invocation.proceed();

    }

}

一气呵成，完美上线。

📚二、发展演变

2.1 业务需求

随着业务发展，出现了以下需求：

• 上下游合作，我们的 PRC 接口在匹配环境上与他们有差异，需要改造

SELECT * FROM ${tableName} WHERE bizId = ${bizId} and env in (?,'all')

• 有一些环境的数据相互相共享，比如预发和灰度等


• 开发人员的部分后面，希望在预发能纠正线上数据等

2.2 初步沟通

这个需求的落地交给了来了快两年的小鲜肉。 在开始做之前，他也问我该怎么做；我简单说了一些想法，比如可以跳过环境字段检查，不拼接条件；或者拼接所有条件，这样都能查询；亦或者看一下能不能注解来标志特定方法，你想一想如何实现......

(●ˇ∀ˇ●)年纪大了需要给年轻人机会。

2.3 勤劳能干

小鲜肉，没多久就实现了。不过有一天下午他遇到了麻烦。他填充的环境字段取出来为 null，看来很久没找到原因，让我帮他看看。（不久前也还教过他 Arthas 如何使用呢，这种问题应该不在话下吧🤔）

2.4 具体实现

大致逻辑：在需要跳过环境条件判断的方法前后做硬编码处理，同环切面逻辑， 一加一删。填充颜色部分为小鲜肉的改造逻辑。

大概逻辑就是：将 env 字段填充所有环境。条件过滤的忽略的目的。

SELECT * FROM ${tableName} WHERE env in ('pre','gray','online','all') AND ${其他条件}

2.5 错误原因

经过排查是因为 API 里面有多处对 threadLoal 进行处理的逻辑，方法之间存在调用。 简化举例： A 和 B 方法都是独立的方法， A 在调用 B 的过程，B 结束时把上下文环境字段删除， A 在获取时得到 null。具体如下：

2.6 五味杂陈

当我看到代码的一瞬间，彻底破防了......

queryProject 方法里面调用 findProjectWithOutEnv，
在两个方法中，都有填充处理 env 的代码。

2.7 遍地开花

然而，这三行代码，随处可见，在业务代码中遍地开花.......

// 1. 变量保存 oriFilterEnv

String oriFilterEnv = UserHolder.getUser().getFilterEnv();



// 2. 设置值到应用上下文

UserHolder.getUser().setFilterEnv(globalConfigDTO.getAllEnv());



//....... 业务代码 ....



// 3. 结束复原

UserHolder.getUser().setFilterEnv(oriFilterEnv);

改了个遍，很勤劳👍......

2.8 灵魂开问

难道真的就只能这么做吗，当然还有......

• 开闭原则符合了吗


• 改漏了应该办呢


• 其他人遇到跳过的检查的场景也加这样的代码吗


• 业务代码和功能代码分离了吗


• 填充到应用上下文对象 user 合适吗


• .......

大量魔法值，单行字符超500，方法长度拖几个屏幕也都睁一眼闭一只眼了，但整这一出，还是破防......

内心涌动😥，我觉得要重构一下。

📒三、重构一下

3.1 困难之处

在 mybatis intercept 中不能直接精准地获取到 service 层的接口调用。 只能通过栈帧查询到调用链。

3.2 问题列表

• 尽量不要修改已有方法，保证不影响原有逻辑；


• 尽量不要在业务方法中修改功能代码；关注点分离；


• 尽量最小改动，修改一处即可实现逻辑；


• 改造后复用能力，而不是依葫芦画瓢地添加这种代码

3.3 实现分析

1. 用独立的 ThreadLocal，不与当前用户信息上下文混合使用


2. 注解+APO，通过注解参数解析，达到目标功能


3. 对于方法之间的调用或者循环调用，要考虑优化

同一份代码，在多个环境运行，不管如何，一定要考虑线上数据安全性。

3.4 使用案例

改造后的使用案例如下，案例说明：project 表在预发环境校验跳过。

@InvokeChainSkipEnvRule(skipEnvList = {"pre"}, skipTableList = {"project"})

@SneakyThrows

@GetMapping("/importSignedUserData")

@InvokeChainSkipEnvRule(skipEnvList = {"pre"}, skipTableList = {"project"})

public void importSignedUserData(

    ......

    HttpServletRequest request,

    HttpServletResponse response) {

    ......

}

在使用的调用入口处添加注解。

3.5 具体实现

1. 方法上标记注解， 注解参数定义规则


2. 切面读取方法上面的注解规则，并传递到应用上下文


3. 拦截器从应用上下文读取规则进行规则判断

注解代码

@Target({ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

public @interface InvokeChainSkipEnvRule {



    /**

     * 是否跳过环境。 默认 true，不推荐设置 false

     *

     * @return

     */

    boolean isKip() default true;



    /**

     * 赋值则判断规则，否则不判断

     *

     * @return

     */

    String[] skipEnvList() default {};



    /**

     * 赋值则判断规则，否则不判断

     *

     * @return

     */

    String[] skipTableList() default {};

}

3.6 不足之处

1. 整个链路上的这个表操作都会跳过，颗粒度还是比较粗


2. 注解只能在入口处使用，公共方法调用尽量避免

🤔那还要不要完善一下，还有什么没有考虑到的点呢？ 拿起手机看到快12点的那一刻，我还是选择先回家了......

📝 四、总结思考

4.1 隔离总结

这是一个很好参考案例：在应用中既做了数据隔离，也做了数据共享。通过自定义拦截器做数据隔离，通过自定注解切面实现数据共享。

4.2 编码总结

同样的代码写两次就应该考虑重构了

• 尽量修改一个地方，不要写这种边边角角的代码


• 善用自定义注解，解决这种通用逻辑


• 可以妥协，但是要有底线


• ......

4.3 场景总结

简单梳理，自定义注解 + AOP 的场景

自定义注解很灵活，应用场景广泛，可以多多挖掘。

4.4 反思总结

• 如果一开始就做好技术方案或者直接使用不同的数据库是否可以解决这个问题


• 是否可以拒绝那个所谓的需求


• 先有设计再有编码

4.5 最后感想

在这个只讲业务结果，不讲技术氛围的环境里，突然有一些伤感；身体已经开始吃不消了，好像也过了那个对技术较真死抠的年纪； 突然一想，这么做的意义又有多大呢?

嗨，大家好，我是飘渺。

最近，我和小伙伴一起接手了一个由外包团队开发的微服务项目，这个项目采用了当前流行的Spring Cloud Alibaba微服务架构，并且是基于一个“大名鼎鼎”的微服务开源脚手架（附带着模块代码截图，相信很多同学一看就能认出来）。然而，在这段时间里，我受到了来自"外包"和"微服务"这双重debuff的折磨。

今天，我想和大家分享一下我在这几天中遇到的问题。希望这几个问题能引起大家的共鸣，以便在未来的微服务开发中避免再次陷入相似的困境。

1、服务模块拆分不合理

绝大部分网上的微服务开源框架都是基于后台管理进行模块拆分的。然而在实际业务开发中，应该以领域建模为基础来划分子服务。

目前的服务拆分方式往往是按照团队或功能来拆分，这种不合理的拆分方式导致了服务调用的混乱，同时增加了分布式事务的风险。

2、微服务拆分后数据库并没拆分

所有服务都共用同一个数据库，这在物理层面无法对数据进行隔离，也导致一些团队为了赶进度，直接读取其他服务的数据表。

这里不禁要问：如果不拆分数据库，那拆分微服务还有何意义？

3、功能复制，不是双倍快乐

在项目中存在一个基础设施模块，其中包括文件上传、数据字典、日志等基础功能。然而，文件上传功能居然在其他模块中重复实现了一遍。就像这样：

4、到处都是无用组件堆彻

在项目的基础模块中，自定义了许多公共的Starter，并且这些组件在各个微服务中被全都引入。比如第三方登录组件、微信支付组件、不明所以的流程引擎组件、验证码组件等等……

拜托，我们已经有自己的SSO登录，不需要微信支付，还有自己的流程引擎。那些根本用不到的东西，干嘛要引入呢？

5、明显的错误没人解决

这个问题是由上面的问题所导致的，由于引入了一个根本不需要的消息中间件，项目运行时不断出现如下所示的连接异常。

项目开发了这么久，出错了这么久，居然没有一个人去解决，真的让人不得不佩服他们的忍受力。

6、配置文件一团乱麻

你看到服务中这一堆配置文件，是不是心里咯噔了一下？

或许有人会说："没什么问题呀，按照不同环境划分不同的配置文件”。可是在微服务架构下，已经有了配置中心，为什么还要这么做呢？这不是画蛇添足吗？

7、乱用配置中心

项目一开始就明确要使用Apollo配置中心，一个微服务对应一个appid，appid一般与application.name一致。

但实际上，多个服务却使用了相同的appid，多个服务的配置文件还塞在了同一个appid下。

更让人费解的是，有些微服务又不使用配置中心。

8、Nacos注册中心混乱

由于项目有众多参与的团队，为了联调代码，开发人员在启动服务时不得不修改配置文件中Nacos的spring.cloud.nacos.discovery.group属性，同时需要启动所有相关服务。

这导致了两个问题：一是某个用户提交了自己的配置文件，导致其他人的服务注册到了别的group，影响他人的联调；二是Nacos注册中心会存在一大堆不同的Gr0up，查找服务变得相当麻烦。

其实要解决这个问题只需要重写一下网关的负载均衡策略，让流量调度到指定的服务即可。据我所知，他们使用的开源框架应该支持这个功能，只是他们不知道怎么使用。

9、接口协议混乱

使用的开源脚手架支持Dubbo协议和OpenFeign调用，然而在我们的项目中并不会使用Dubbo协议，微服务之间只使用OpenFeign进行调用。然而，在对外提供接口时，却暴露了一堆支持Dubbo协议的接口。

10、部署方式混乱

项目部署到Kubernetes云环境，一般来说，服务部署到云上的内部服务应该使用ClusterIP的方式进行部署，只有网关服务需要对外访问，网关可以通过NodePort或Ingress进行访问。

这样做可以避免其他人或服务绕过网关直接访问后端微服务。

然而，他们的部署方式是所有服务都开启了NodePort访问，然后在云主机上还要部署一套Nginx来反向代理网关服务的NodePort端口。

结语

网络上涌现着众多微服务开源脚手架，它们吸引用户的方式是将各种功能一股脑地集成进去。然而，它们往往只是告诉你“如何集成”却忽略了“为什么要集成”。

尽管这些开源项目能够在学习微服务方面事半功倍，但在实际微服务项目中，我们不能盲目照搬，而应该根据项目的实际情况来有选择地裁剪或扩展功能。这样，我们才能更好地应对项目的需求，避免陷入不必要的复杂性，从而更加成功地实施微服务架构。

最后，这个开源项目你们认识吗？

关注公众号 Java日知录 获取更多精彩文章

前言

身为后端程序员怎么也要会一点压力测试相关的技术吧, 不然无脑上线项目万一项目火了进来大量请求时出现程序执行缓慢, 宕机等情况你肯定稳稳背锅, 而且这个时候短时间内还没办法解决, 只能使用物理扩容CPU, 内存, 更换网络等几种方式来解决问题, 妥妥的为公司增加支出好吧, 下一个被开的就是你

都是想跑路拿高薪的打工仔, 身上怎么可以背负污点, 赶紧学一手压力测试进行保命, 我先学为敬

本篇文章主打一个学完就会, 奥利给

文中出现软件的版本

• JMeter: 5.5


• ServerAgent: 2.2.3

性能调优对各个开发岗位的区别

各个岗位对性能调优的关键节点

• 前端工程师:
  
  
  
  • 首屏时间: 初次访问项目等待加载时间
  
  
  • 白屏时间: 刷新页面到数据全部展示时间
  
  
  • 可交互时间
  
  
  • 完全加载时间
  
  
  
  


• 后端工程师
  
  
  
  • RT: 响应时间
  
  
  • TRS: 每秒事务数
  
  
  • 并发数: 这应该不会解释了吧
  
  
  
  


• 移动端工程师
  
  
  
  • 端到端相应时间
  
  
  • Crash率
  
  
  • 内存使用率
  
  
  • FPS
  
  
  
  

主要讲一下后端工程师(Java), 毕竟这是吃饭的家伙

对于后端工程师来说, 影响性能的地方主要有两个

• 数据库读写, RPC, 网络IO, 代码逻辑复杂度, 缓存


• JVM(Throughput)
  - JVM(Throughput)

影响性能的关键要素

• 产品设计
  
  
  
  • 产品逻辑
  
  
  • 功能交互
  
  
  • 动态效果
  
  
  • 页面元素
  
  
  
  


• 基础网络


• 代码质量&架构
  
  
  
  • 架构不合理
  
  
  • 研发功底和经验不足
  
  
  • 没有性能意识: 只实现功能不注重代码性能, 当业务上量后系统出现连锁反应, 导致性能问题增加
  
  
  • 数据库: 慢查询, 过多查询, 索引使用不当, 数据库服务器瓶颈
  
  
  
  


• 用户移动端环境
  
  
  
  • 设备类型&性能
  
  
  • 系统版本
  
  
  • 网络(WiFi, 2G, 3G, 4G, 5G)
  
  
  • 硬件及云服务(服务器硬件, CPU, 内存..)
  
  
  
  

1. 初步了解压力测试

1.1压力测试是什么

压力测试是针对特定系统或组件, 为要确定其稳定性而特意进行的严格测试. 会让系统在超过正常使用条件下运作, 然后再确认其结果

对系统不断施加压力, 来预估系统`负载能力`的一种测试



一般而言, 只有在系统基础功能测试验证完成, 系统趋于稳定的情况下, 才会进行压力测试

1.2压力测试的目的

当负载主键增加时, 观察系统各项性能指标的变化情况是否有异常

发现系统的性能短板, 进行针对性的性能优化

判断系统在**高并发情况下是否会报错**, 进行是否会挂掉

测试在系统某个方面达到瓶颈时, 粗略估计系统性能上限

1.3 压力测试的指标

评判系统性能, 主要考虑三个性能指标 RT, TPS, 资源利用率

上图充分的展示了响应时间, 吞吐量, 利用率和并发用户数之间的关系

随着并发用户的增加经过轻负载区, 达到最优并发数, 此时利用率高,吞吐量高, 响应时间短

但是如果用户数继续增加, 就会到达重负载区, 此时性能最大化, 但是当超过某一临界值(最大并发数)之后, 响应时间会急剧增加, 利用率平缓, 吞吐量急速下降

我们进行压测的目的主要就是测试出这个临界值的大小, 或者说, 我们系统当前能承受住的最大并发数

2. 压力测试工具 JMeter

老规矩, 先来一波软件介绍
JMeter是 Apache组织开发的基于 Java的开源压力测试工具, 具有体积小, 功能全, 使用方便等特点. 最初被设计用于 Web应用测试, 后来被扩展到其他测试领域.

常用压测工具:

• Apache JMeter可视化的测试工具


• LoadRunner 预测系统行为和性能的负载测试工具


• Apache的 ab压力测试


• nGrinder韩国研发的一款性能测试工具


• PAS阿里测试工具

压测目标:

• 负载上升各项指标是否正常


• 发现性能短板


• 高并发下系统是否稳定


• 预估系统最大负载

2.1 安装 JMeter

写在前面, 需要 Java8环境, 没有的话需要去安装, 教程百度上一大堆

官网地址: jmeter.apache.org/

熟悉的download, 点他

开始下载(是真的慢)

解压之后进入 bin目录下, 双击 jmeter.bat, 就可以启动 JMeter了

上图可以看出, 在我们第一次打开界面时是英文的, 多少有点不友好, 接下来讲解一下怎么将语言更改为中文

2.2 设置 JMeter界面为中文

还是我们的 bin目录下, 有一个 jmeter.properties文件

双击打开, 搜索 language

去除 #号, 值更改为 zh_CN, 保存文件然后重启软件(双击jmeter.bat)

可以看到, 我们的 jmeter成功更改为了中文界面, 这对于我这种英语白痴来说是很舒服的

2.3 初步使用 JMeter

我们先随便创建一个测试用例, 就是简单测试, 同时讲解一下常用的参数

本次测试采用 20线程, 1秒启动时间, 循环100次, Get请求

2.3.1 创建线程组

• 线程数: 虚拟的用户数, 一个用户占一个线程


• Ramp-Up: 等待时间, 设置的虚拟用户(线程数)需要多长时间全部启动


• 循环次数: 单个线程发送请求的次数


• 调度器:
  
  
  
  • 持续时间: 该任务执行的时间
  
  
  • 启动延迟: 等待多少秒开始执行
  
  
  
  

2.3.2 创建 http请求

右键线程组-添加HTTP请求

这个中文讲解的很明白, 应该都看得懂的, 有疑问的评论区留言

2.3.3 结果树

结果树, 聚合报告, 图形结果只有新增, 解释在测试

线程组右键-添加-监听器-查看结果树

执行结果分析(启动之后显示界面)

列表列出了每一次的HTTP请求, 绿色的是成功, 红色的话就是失败

• 取样器结果参数详解
  
  
  
  • Thread Name：线程组名称
  
  
  • Sample Start: 启动开始时间
  
  
  • Load time：加载时长
  
  
  • Latency：等待时长
  
  
  • Size in bytes：发送的数据总大小
  
  
  • Headers size in bytes：发送数据的其余部分大小
  
  
  • Sample Count：发送统计
  
  
  • Error Count：交互错误统计
  
  
  • Response code：返回码
  
  
  • Response message：返回信息
  
  
  • Response headers：返回的头部信息
  
  
  
  


• 请求
  
  
  
  • 基本数据
  
  
  • 入参
  
  
  • 请求头
  
  
  
  


• 相应数据
  
  
  
  • 响应码
  
  
  • 响应头
  
  
  
  

2.3.4 聚合报告

线程组右键-添加-监听器-聚合报告

执行结果分析(启动之后界面)

参数解释

• 样本: 并发量


• 平均值: 接口请求用时(单位毫秒)


• 中位数: 请求用时中位数(单位毫秒), 例如2000请求以请求时间排序, 排名1000的用时时长


• 90%百分位, 95%百分位, 99%百分位和中位数同理


• 最小, 最大值: 请求用时最小和最大


• 异常% : 请求中异常的百分比


• 吞吐量: 单位时间内请求次数

2.3.5 图形结果

线程组右键-添加-监听器-图形结果

执行结果分析(启动之后显示界面)

• 样本数目：总共发送到服务器的请求数。


• 最新样本：代表时间的数字，是服务器响应最后一个请求的时间。


• 吞吐量：服务器每分钟处理的请求数。


• 平均值：总运行时间除以发送到服务器的请求数。


• 中间值：有一半的服务器响应时间低于该值而另一半高于该值。


• 偏离：表示服务器响应时间变化、离散程度测量值的大小。

2.3.6 断言

断言主要用来判断结果返回是否符合预期

线程组右键-添加-断言-响应断言

假设我们接口的返回状态码字段为code, 200为成功, 那么就可以在断言这里进行配置, 来判断请求是否成功

3. JMeter插件

3.1 插件安装

首先说明 JMeter是不支持插件的, 所以我们先要 JMeter的插件允许插件下载, 这句话多少有点拗口

网址: Install :: JMeter-Plugins.org

点击上图红框即可下载插件, 前面说过了 JMeter是 Java8开发的, 插件对应的也是一个 jar包

下好之后就可以放在 JMeter安装目录下的 lib/ext/ 下了, 具体下载页面也有说明

上述操作结束之后, 在选项里面就可以看到插件中心Plugins Manager

弹出以下界面, 点击 Available Plugins搜索我们需要的插件Basic Graphs和Additional Graphs, 勾选上, 然后安装

Basic Graphs主要显示显示平均响应时间，活动线程数，成功/失败交易数等

Additional Graphs主要显示吞吐量，连接时间，每秒的点击数等

在安装成功之后, 在监听器会相应的多出很多的 jc开头的, 这就代表安装成功了

我使用的是 5.5版本的, 之前版本安装之后好像要手动重启, 5.5安装完会自动重启

4. Linux硬件监控

在压测过程中, 我们需要实时了解服务器的CPU, 内存, 网络, 服务器负载等情况的变化, 这个时候我们就需要对我们的 Linux系统进行监控, 通常来讲, 我们查询 Linux系统的资源占用情况可以使用以下几种方法

• 使用命令: top, iostat, iotop等


• 使用 Linux远程连接工具 FinalShell等


• 宝塔


• JMeter压测工具 PerfMon

在 JMeter中, 如果需要监控服务器硬件, 那么我们还需要安装 PerfMon插件

PerfMon监控服务器硬件，如CPU，内存，硬盘读写速度等

进入下述地址开始下载监控包: github.com/undera/perf…

下载好之后我们可以直接解压放到服务器上, 会看到有两个startAgent文件, 分别是Windows系统和Linux系统的启动脚本

我们直接启动就可以了, 如果脚本启动连接不上的话可以考虑更改脚本内容

例: Linux系统脚本更改为以下内容

## 默认启动运行 startAgent.sh 脚本即可



## 服务启动默认4444端口，根本连接不上，因此自己创建一个部署脚本文件对此进行部署，且把端口修改为7879



nohup java -jar ./CMDRunner.jar --tool PerfMonAgent --udp-port 7879 --tcp-port 7879 > log.log 2>&1 &



## 赋予可执行权限



chmod 755 startAgent.sh

启动成功之后, 脚本同级路径下会多出 log.log的日志文件

然后我们就可以配置 JMeter了, 线程组-监听器-jp@gc - PerfMon Metrics Collector

我是在本地启动了ServerAgent.bat进行测试, 执行结果如下所示:

注: 文件必须配置, 不然没有图像

具体的配置指标信息建议看官方文档, 太多了....
github.com/undera/perf…

ServerAgent闪退问题

Windows系统配置好ServerAgent启动之后窗口闪退可能是 jre版本问题, 可以从下面的链接下载老版的 jre

http://www.aliyundrive.com/s/Yzw3DZ74w…

下载好之后, 建议安装目录设置在ServerAgent/jre下

并更改startAgent.bat脚本, cd 到老版本 jre路径

1、在任意目录之间快速移动

你发现自己要在两个或更多目录之间频繁移动，一会切换到这里，一会切换到那里，来回跳转。这些目录之间隔得还挺远，反复输入冗长的路径让人疲惫不堪。

使用内建命令 pushd 和 popd 来管理目录栈，轻松地在目录之间切换。下面是一个简单的示例：

$ cd /tmp/tank

$ pwd

/tmp/tank



$ pushd /var/log/cups

/var/log/cups /tmp/tank



$ pwd

/var/log/cups



$ ls

access_log error_log page_log



$ popd

/tmp/tank



$ ls

empty full



$ pushd /var/log/cups

/var/log/cups /tmp/tank



$ pushd

/tmp/tank /var/log/cups



$ pushd

/var/log/cups /tmp/tank



$ pushd

/tmp/tank /var/log/cups



$ dirs

/tmp/tank /var/log/cups

栈是一种后进先出的结构，这两个命令也正是这么做的。如果对一个新目录使用 pushd，那么它会将前一个目录压入栈中。当使用 popd时，它会弹出栈顶保存的当前位置，切换到新的栈顶目录。使用这些命令更改位置时，会从左到右输出目录栈中的值，对应于栈中自顶向下的顺序。

如果使用 pushd 时没有指定目录，那么它会交换栈顶的两个目录的位置，这样就可以重复使用 pushd 命令来实现两者之间的切换。cd命令也能够达到相同效果。

如果不记得目录栈中都有哪些目录，可以使用内建命令 dirs 按照从左到右的顺序显示。加上 -v 选项后，显示形式更形象。

$ dirs -v

 0  /opt/yongheng

 1  /opt/yongheng/Shell

$

数字可用来调整栈内目录的位置。pushd +1 会将编号为 1 的目录置为栈顶（并切换到该目录）并将其他目录下压。

$  pushd +1

/opt/yongheng/Shell /opt/yongheng



$  dirs -v 

0  /opt/yongheng/Shell

1  /opt/yongheng 

要想看到类似于栈的目录列表，但又不希望出现编号，可以使用 -p选项。

# dirs -p                                                                                              /opt/yongheng/Shell                                                                                    /opt/yongheng     

2、重复上一个命令

你刚刚输入了一个又长又麻烦的命令，其中包含了冗长的路径名和一堆复杂的参数。现在需要重新执行该命令。难道还得再输入一次？

这个问题有两种解决方法。第一种方法只需要在提示符下输入两个惊叹号，然后 bash 就会显示并重复执行上一个命令。例如：

$  cd /opt/                                                                                            $ !!                                                                                                   cd /opt/  

另一种（更现代的）方法是使用箭头键。按上箭头键会回滚到执行过的上一个命令。如果找到了需要的命令，按下 Enter 键就可以（再次）执行该命令。

3、参数重用

重用上一个命令很简单，使用 !! 就行了，但你需要的未必总是整个命令。如何只重用最后一个参数呢？

用 !$ 指明上一个命令中的最后一个参数。!:1 表示第一个参数，!:2 表示第二个参数，以此类推。

多个命令使用相同的文件名为参数是司空见惯的事情。最常见的场景之一就是程序员编辑源代码文件，然后编译、再编辑，再编译……有了 !$，事情就方便多了。如下：

$ vi /some/long/path/name/you/only/type/once

...

$ gcc !$

gcc /some/long/path/name/you/only/type/once

...

$ vi !$

vi /some/long/path/name/you/only/type/once

...

$ gcc !$

gcc /some/long/path/name/you/only/type/once

...

$

明白其中的意思了吗？这不仅省去了大量的键盘输入，还避免了错误。如果编译时输错文件名，那编译的可就不是刚刚编辑好的源代码文件了。有了 !$，就可以始终得到刚刚用过的文件名。要是想重用的参数位于命令行内部，可以使用带编号的 !: 命令来获取。

4、安全第一，命令测试

一不小心就会输错字符。 （不信你瞧！）即便是简单的 bash 命令，由此带来的后果也非常严重：你会移动错或删错文件。如果再加上模式匹配，结果更让人心跳，因为模式中的输入错误会导致南辕北辙的结果。小心谨慎的用户会怎么做？

可以使用命令历史特性和键盘便捷方式来重复参数，无须从头输入，因此能够减少输入错误。如果要用到棘手的模式来匹配文件，先用echo 测试一下模式能否正常匹配，然后再用 !$ 进行实际操作。例如：

$ ls

ab1.txt ac1.txt jb1.txt wc3.txt



$ echo *1.txt

ab1.txt ac1.txt jb1.txt



$ echo [aj]?1.txt

ab1.txt ac1.txt jb1.txt



$ echo ?b1.txt

ab1.txt jb1.txt



$ rm !$

rm ?b1.txt

$

echo 是检查模式匹配结果的一种方法。一旦确信结果符合预期，就可以将模式用于实际命令。这里我们要删除有特定名称的文件，没人愿意在这种事上犯错。

一、什么是压缩炸弹，会有什么危害

1.1 什么是压缩炸弹

压缩炸弹(ZIP)：一个压缩包只有几十KB，但是解压缩后有几十GB，甚至可以去到几百TB，直接撑爆硬盘，或者是在解压过程中CPU飙到100%造成服务器宕机。虽然系统功能没有自动解压，但是假如开发人员在不细心观察的情况下进行一键解压(不看压缩包里面的文件大小)，可导致压缩炸弹爆炸。又或者压缩炸弹藏在比较深的目录下，不经意的解压缩，也可导致压缩炸弹爆炸。

以下是安全测试几种经典的压缩炸弹

graph LR

A(安全测试的经典压缩炸弹)

B(zip文件42KB)

C(zip文件10MB)

D(zip文件46MB)

E(解压后5.5G)

F(解压后281TB)

G(解压后4.5PB)



A ---> B --解压--> E

A ---> C --解压--> F

A ---> D --解压--> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style F fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style G fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

压缩炸弹（也称为压缩文件炸弹、炸弹文件）是一种特殊的文件，它在解压缩时会迅速膨胀成极其庞大的文件，可能导致系统资源耗尽、崩溃或磁盘空间耗尽。

压缩炸弹的原理是利用文件压缩算法中的重复模式和递归压缩的特性。它通常是一个非常小的压缩文件，但在解压缩时会生成大量的重复数据，导致文件大小迅速增长。这种文件的设计意图是迫使系统进行大量的解压缩操作，以消耗系统资源或填满磁盘空间。

压缩炸弹可能对系统造成严重的影响，包括系统崩溃、资源耗尽、拒绝服务攻击等。因此，它被视为一种恶意的计算机攻击工具，常常被用于恶意目的或作为安全测试中的一种工具。

1.2 压缩炸弹会有什么危害

graph LR

A(压缩炸弹的危害)

B(资源耗尽)

C(磁盘空间耗尽)

D(系统崩溃)

E(拒绝服务攻击)

F(数据丢失)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

压缩炸弹可能对计算机系统造成以下具体的破坏：

1. 
   

   资源耗尽：压缩炸弹在解压缩时会生成大量的重复数据，导致系统的CPU、内存和磁盘资源被迅速占用。这可能导致系统反应迟缓、无法响应用户的请求，甚至系统崩溃。

   
   


2. 
   

   磁盘空间耗尽：由于压缩炸弹的膨胀特性，它可能在解压缩过程中填满磁盘空间。这会导致系统无法写入新的数据，造成磁盘空间耗尽，影响系统的正常运行。

   
   


3. 
   

   系统崩溃：当一个压缩炸弹被解压缩时，系统可能由于资源耗尽或磁盘空间耗尽而崩溃。这可能导致系统重启或需要进行紧急修复，造成数据丢失或系统不可用的情况。

   
   


4. 
   

   拒绝服务攻击：大规模的解压缩操作可能消耗大量系统资源，导致系统无法正常提供服务。这被恶意攻击者利用，用于进行拒绝服务攻击，使目标系统无法响应合法用户的请求。

   
   


5. 
   

   数据丢失：在某些情况下，压缩炸弹可能会导致系统文件或数据的损坏或丢失。这可能发生在磁盘空间被耗尽时，写入操作无法成功完成的情况下。

   
   

重要提示：压缩炸弹可能对计算机系统造成不可逆的损害，请不要尝试创建、传播或使用压缩炸弹，以保护计算机和网络的安全。

二、怎么检测和处理压缩炸弹，Java怎么防止压缩炸弹

2.1 个人有没有方法可以检测压缩炸弹？

有一些方法可以识别和处理潜在的压缩炸弹，以防止对系统造成破坏。以下是一些常见的方法：

graph LR

A(个人检测压缩炸弹)

B(安全软件和防病毒工具)

C(文件大小限制)

D(文件类型过滤)



A ---> B --> E(推荐)

A ---> C --> F(太大的放个心眼)

A ---> D --> G(注意不认识的文件类型)



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style F fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style G fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

1. 
   

   安全软件和防病毒工具（推荐）：使用最新的安全软件和防病毒工具可以帮助检测和阻止已知的压缩炸弹。这些工具通常具备压缩文件扫描功能，可以检查文件是否包含恶意的压缩炸弹。

   
   


2. 
   

   文件大小限制：设置对文件大小的限制可以帮助防止解压缩过程中出现过大的文件。通过限制解压缩操作的最大文件大小，可以减少对系统资源和磁盘空间的过度消耗。

   
   


3. 
   

   文件类型过滤：识别和过滤已知的压缩炸弹文件类型可以帮助阻止这些文件的传输和存储。通过检查文件扩展名或文件头信息，可以识别潜在的压缩炸弹，并阻止其传输或处理。

   
   

2.2 Java怎么防止压缩炸弹

在java中实际防止压缩炸弹的方法挺多的，可以采取以下措施来防止压缩炸弹：

graph LR

A(Java防止压缩炸弹)

B(解压缩算法的限制)

C(设置解压缩操作的资源限制)

D(使用安全的解压缩库)

E(文件类型验证和过滤)

F(异步解压缩操作)

G(安全策略和权限控制)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F

A ---> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

1. 
   

   解压缩算法的限制：限制解压缩算法的递归层数和重复模式的检测可以帮助防止解压缩过程无限膨胀。通过限制递归的深度和检测重复模式，可以及时中断解压缩操作并避免过度消耗资源。

   
   


2. 
   

   设置解压缩操作的资源限制：使用Java的java.util.zip或java.util.jar等类进行解压缩时，可以设置解压缩操作的资源限制，例如限制解压缩的最大文件大小、最大递归深度等。通过限制资源的使用，可以减少对系统资源的过度消耗。

   
   


3. 
   

   使用安全的解压缩库：确保使用的解压缩库是经过安全验证的，以避免存在已知的压缩炸弹漏洞。使用官方或经过广泛验证的库可以减少受到压缩炸弹攻击的风险。

   
   


4. 
   

   文件类型验证和过滤：在解压缩之前，可以对文件进行类型验证和过滤，排除潜在的压缩炸弹文件。通过验证文件的类型、扩展名和文件头信息，可以识别并排除不安全的压缩文件。

   
   


5. 
   

   异步解压缩操作：将解压缩操作放在异步线程中进行，以防止阻塞主线程和耗尽系统资源。这样可以保持应用程序的响应性，并减少对系统的影响。

   
   


6. 
   

   安全策略和权限控制：实施严格的安全策略和权限控制，限制用户对系统资源和文件的访问和操作。确保只有受信任的用户或应用程序能够进行解压缩操作，以减少恶意使用压缩炸弹的可能性。

   
   

2.2.1 使用解压算法的限制来实现防止压缩炸弹

在前面我们说了Java防止压缩炸弹的一些策略，下面我将代码实现通过解压缩算法的限制来实现防止压缩炸弹。

先来看看我们实现的思路：

graph TD

    A(开始) --> B[创建 ZipFile 对象]

    B --> C[打开要解压缩的 ZIP 文件]

    C --> D[初始化 zipFileSize 变量为 0]

    D --> E{是否有更多的条目}

    E -- 是 --> F[获取 ZIP 文件的下一个条目]

    F --> G[获取当前条目的未压缩大小]

    G --> H[将解压大小累加到 zipFileSize 变量]

    H --> I{zipFileSize 是否超过指定的大小}

    I -- 是 --> J[调用 deleteDir方法删除已解压的文件夹]

    J --> K[抛出 IllegalArgumentException 异常]

    K --> L(结束)

    I -- 否 --> M(保存解压文件) --> E

    E -- 否 --> L

 

style A fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style H fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style J fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style K fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style L fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style M fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

实现流程说明如下：

1. 
   

   首先，通过给定的 file 参数创建一个 ZipFile 对象，用于打开要解压缩的 ZIP 文件。

   
   


2. 
   

   zipFileSize 变量用于计算解压缩后的文件总大小。

   
   


3. 
   

   使用 zipFile.entries() 方法获取 ZIP 文件中的所有条目，并通过 while 循环逐个处理每个条目。

   
   


4. 
   

   对于每个条目，使用 entry.getSize() 获取条目的未压缩大小，并将其累加到 zipFileSize 变量中。

   
   


5. 
   

   如果 zipFileSize 超过了给定的 size 参数，说明解压后的文件大小超过了限制，此时会调用 deleteDir() 方法删除已解压的文件夹，并抛出 IllegalArgumentException 异常，以防止压缩炸弹攻击。

   
   


6. 
   

   创建一个 File 对象 unzipped，表示解压后的文件或目录在输出文件夹中的路径。

   
   


7. 
   

   如果当前条目是一个目录，且 unzipped 不存在，则创建该目录。

   
   


8. 
   

   如果当前条目不是一个目录，确保 unzipped 的父文件夹存在。

   
   


9. 
   

   创建一个 FileOutputStream 对象 fos，用于将解压后的数据写入到 unzipped 文件中。

   
   


10. 
    

    通过 zipFile.getInputStream(entry) 获取当前条目的输入流。

    
    


11. 
    

    创建一个缓冲区 buffer，并使用循环从输入流中读取数据，并将其写入到 fos 中，直到读取完整个条目的数据。

    
    


12. 
    

    最后，在 finally 块中关闭 fos 和 zipFile 对象，确保资源的释放。

    
    

实现代码工具类：

import java.io.File;

import java.io.FileOutputStream;

import java.io.InputStream;

import java.util.Enumeration;

import java.util.zip.ZipEntry;

import java.util.zip.ZipFile;



/**

 * 文件炸弹工具类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2023/10

 */

public class FileBombUtil {



    /**

     * 限制文件大小 1M（限制单位：B）[1M=1024KB 1KB=1024B]

     */

    public static final Long FILE_LIMIT_SIZE = 1024 * 1024 * 1L;



    /**

     * 文件超限提示

     */

    public static final String FILE_LIMIT_SIZE_MSG = "The file size exceeds the limit";



    /**

     * 解压文件（带限制解压文件大小策略）

     *

     * @param file         压缩文件

     * @param outputfolder 解压后的文件目录

     * @param size         限制解压之后的文件大小（单位：B），示例 3M：1024 * 1024 * 3L （FileBombUtil.FILE_LIMIT_SIZE * 3）

     * @throws Exception IllegalArgumentException 超限抛出的异常

     *                   注意：业务层必须抓取IllegalArgumentException异常，如果msg等于FILE_LIMIT_SIZE_MSG

     *                   要考虑后面的逻辑，比如告警

     */

    public static void unzip(File file, File outputfolder, Long size) throws Exception {

        ZipFile zipFile = new ZipFile(file);

        FileOutputStream fos = null;

        try {

            Enumeration<? extends ZipEntry> zipEntries = zipFile.entries();

            long zipFileSize = 0L;

            ZipEntry entry;

            while (zipEntries.hasMoreElements()) {

                // 获取 ZIP 文件的下一个条目

                entry = zipEntries.nextElement();

                // 将解缩大小累加到 zipFileSize 变量

                zipFileSize += entry.getSize();

                // 判断解压文件累计大小是否超过指定的大小

                if (zipFileSize > size) {

                    deleteDir(outputfolder);

                    throw new IllegalArgumentException(FILE_LIMIT_SIZE_MSG);

                }

                File unzipped = new File(outputfolder, entry.getName());

                if (entry.isDirectory() && !unzipped.exists()) {

                    unzipped.mkdirs();

                    continue;

                } else if (!unzipped.getParentFile().exists()) {

                    unzipped.getParentFile().mkdirs();

                }



                fos = new FileOutputStream(unzipped);

                InputStream in = zipFile.getInputStream(entry);



                byte[] buffer = new byte[4096];

                int count;

                while ((count = in.read(buffer, 0, buffer.length)) != -1) {

                    fos.write(buffer, 0, count);

                }

            }

        } finally {

            if (null != fos) {

                fos.close();

            }

            if (null != zipFile) {

                zipFile.close();

            }

        }



    }



    /**

     * 递归删除目录文件

     *

     * @param dir 目录

     */

    private static boolean deleteDir(File dir) {

        if (dir.isDirectory()) {

            String[] children = dir.list();

            //递归删除目录中的子目录下

            for (int i = 0; i < children.length; i++) {

                boolean success = deleteDir(new File(dir, children[i]));

                if (!success) {

                    return false;

                }

            }

        }

        // 目录此时为空，可以删除

        return dir.delete();

    }



}

测试类：

import java.io.File;



/**

 * 文件炸弹测试类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2023/10

 */

public class Test {



    public static void main(String[] args) {

        File bomb = new File("D:\temp\3\zbsm.zip");

        File tempFile = new File("D:\temp\3\4");

        try {

            FileBombUtil.unzip(bomb, tempFile, FileBombUtil.FILE_LIMIT_SIZE * 60);

        } catch (IllegalArgumentException e) {

            if (FileBombUtil.FILE_LIMIT_SIZE_MSG.equalsIgnoreCase(e.getMessage())) {

                FileBombUtil.deleteDir(tempFile);

                System.out.println("原始文件太大");

            } else {

                System.out.println("错误的压缩文件格式");

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

    }



}

三、总结

文件炸弹是一种恶意的计算机程序或文件，旨在利用压缩算法和递归结构来创建一个巨大且无限增长的文件或文件集
合。它的目的是消耗目标系统的资源，如磁盘空间、内存和处理能力，导致系统崩溃或无法正常运行。文件炸弹可能是有意制造的攻击工具，用于拒绝服务（DoS）攻击或滥用资源的目的。

文件炸弹带来的危害极大，作为开发人员，我们必须深刻认识到文件炸弹的危害性，并始终保持高度警惕，以防止这种潜在漏洞给恐怖分子以可乘之机。

总而言之，我们作为开发人员，要深刻认识到文件炸弹的危害性，严防死守，不给恐怖分子任何可乘之机。通过使用安全工具、限制文件大小、及时更新软件、定期备份数据以及加强安全意识，我们可以有效地防止文件炸弹和其他恶意活动对系统造成损害。

在中国，网络安全和计算机犯罪问题受到相关法律法规的管理和监管。以下是一些中国关于网络安全和计算机犯罪方面的法律文献，其中也涉及到文件炸弹的相关规定：

1. 
   

   《中华人民共和国刑法》- 该法律规定了各种计算机犯罪行为的法律责任，包括非法控制计算机信息系统、破坏计算机信息系统功能、非法获取计算机信息系统数据等行为，这些行为可能涉及到使用文件炸弹进行攻击。

   
   


2. 
   

   《中华人民共和国网络安全法》- 该法律是中国的基本法律，旨在保障网络安全和维护国家网络空间主权。它规定了网络安全的基本要求和责任，包括禁止制作、传播软件病毒、恶意程序和文件炸弹等危害网络安全的行为。

   
   


3. 
   

   《中华人民共和国计算机信息系统安全保护条例》- 这是一项行政法规，详细规定了计算机信息系统安全的保护措施和管理要求。其中包含了对恶意程序、计算机病毒和文件炸弹等威胁的防范要求。

   
   

面试官：小伙子，了解HashMap吗?

学弟：哎呦，你干嘛～ 真的问这个呀....

面试官：呦，练习时长两年半？待会答不上来，你可就遭老罪喽！

那行吧，那开始吧...唱跳rap篮球🏀......

一、HashMap的底层结构

说一下你理解的HashMap底层？

hashMap是由数值和链表组合而成的数据结构，存储为key Value形式。

在java7中叫entry，数据形式为数组+链表。java8中叫Node，数据形式为数组+链表+红黑树（当链表长度大于8时转为红黑树）。

每一个节点都会保存自身的hash、key、value、以及next属性指向下一个节点。

二、为什么使用数组+链表数据结构

你刚提到了使用数组+链表，可以讲讲为什么使用这个结构吗？

HashMap内部使用数组来存储键值对，这个数组就是 HashMap 的主体。

在数组中存储的每个位置上，可能会有多个键值对，这些键值对通过链表的形式链接在一起。

使用数组+链表的数据结构是为了解决散列表中的键冲突问题。在散列表中，每个键都会被映射到一个桶中，但是不同的键可能会被映射到同一个桶中，这种情况被称为键冲突。

为了解决键冲突问题，HashMap 采用了链表的形式将所有映射到同一个桶中的键值对链接在一起，这样就可以通过遍历链表来查找指定键的值。当链表长度过长时，查找效率就会下降，因此在链表长度超过一定阈值（8）后，HashMap会将链表转换为红黑树，以提高查找效率。

同时，数组的优势在于支持通过下标快速访问元素，因此HashMap可以将每个桶的位置映射到数组的一个元素上，通过下标访问该元素即可访问到对应的链表或红黑树。

我们都知道：数组的查询效率很高，添加和删除的效率低。链表的查询效率很低，添加和删除的效率高。

因此：使用数组加链表形式，不仅可以解决散列表中的键冲突问题，且数组的查询效率高、链表的添加和删除效率高。结合在一起，增删查效率都很高。

嗯，确实不错。不愧是练习时长两年半的程序员.....

三、数组+链表+红黑树

你刚说数组+链表+红黑树，什么情况下会转化红黑树？什么情况下转数组呢？

链表中元素过多，会影响查找效率，当其个数达到8的时候转换为红黑树。红黑树是平衡二叉树，在查找性能方面比链表要高。

当红黑树的节点数小于等于6时，红黑树转换为链表，是为了减少内存开销。

需要注意的是：将链表转换为红黑树、红黑树转换为链表的操作会影响HashMap的性能，因此需要尽可能避免这种情况的发生。同时，当HashMap中的元素数量较小时，不会出现链表转换为红黑树的情况，因此使用HashMap时，可以考虑在元素数量较少的情况下使用HashMap，以提高性能。

四、头插法和尾插法

说一下什么是头插法，什么是尾插法？

哇，这不是为难我胖虎吗？啥是头插法？啥是尾插法？

4.1、头插法

顾名思义，头插法就是新增元素时，放在最前面嘛。

举个栗子🌰，楼主画了一个简单的框框。用来表示原有存储顺序依次为1、2、3的数组。

假设现在加入了一个4，如果使用头插法，就会变为4123。

4.2、尾插法

同样道理，尾插法就是新增元素时，放在最后面。

还是原有存储顺序依次为1、2、3的数组。

假设现在加入了一个4，如果使用尾插法，就会变为1234。

头插法为什么要调整为尾插法呢？

为什么头插法要调整为尾插法？这是个好问题！！！

java7中使用头插法，新来的值会取代原有的值，原有的值就顺推到链表中。在这种情况下，引用关系可能会乱掉，严重会造成死循环。java8使用尾插法，把元素放到最后，就不会出现这种情况。

五、HashMap如何运算存储索引

向一个hashMap中存入数据时，如何知道数据放在哪个位置呢？

当向一个hashMap中存入数据时，会先根据key的哈希值决定放在数组中哪个索引位置。

Hash公式：index = HashCode（Key） & （Length - 1）

如果数组中该索引位置是空的，直接将元素放入，如果该索引位置已经存在元素了，就根据equals方法判断下已有的元素是否和我们新放入的元素是同一个，如果返回true是同一个，则覆盖掉。不是同一元素则在原有元素下面使用链表进行存储。

每个元素都有一个next属性指向下一个节点（数组+链表）

    /**

     * Basic hash bin node, used for most entries.  (See below for

     * TreeNode subclass, and in LinkedHashMap for its Entry subclass.)

     */

    static class Node<K,V> implements Map.Entry<K,V> {

        final int hash;

        final K key;

        V value;

        Node<K,V> next;

        .........

    }

六、HashMap初始化、扩容

嗯，你知道HashMap默认初始化大小是多少吗？还有它的扩容？

HashMap默认初始化容量大小是16，最大容量为2的30次方，负载因子是0.75。

扩容时，会把原有数组中的值取出再次hash到新的数组中（长度扩大以后，Hash的规则也随之改变），因此性能消耗也相对较大。

当HashMap中的元素数量超过负载因子（默认为 0.75）乘以数组长度时，就会触发扩容操作，将数组长度增加一倍，并重新计算每个元素在新数组中的位置。

七、hash碰撞是什么

你听说过hash碰撞吗？

hash碰撞就是不同的Key，经过同一散列算法之后得到的hashCode值相同。

hashCode不同，key一定不同。hashCode相同，key却不一定相同。

当两个key的hashCode()返回值不同时，它们对应哈希表索引也一定不同。不同的key对象，即使它们包含相同的属性、值或状态，它们的hashCode()返回值也是不相同的。

当两个key的hashCode()返回值相同时，它们可能对应同一个哈希表索引，但它们并不一定相等。在哈希表中，不同的key可能会产生相同的哈希值（哈希碰撞）。

因此，当 key的hashCode相同时，还需要比较key的相等性。需要调用key的equals() 方法来判断它们是否相等。只有当hashCode相等，且equals方法返回true时。才可以认为这两个key相等。

八、如何解决hash碰撞

解决hash碰撞的方法有哪些呢？

在哈希表中，哈希碰撞可能会导致性能下降或者安全问题。

常见的解决方法有：

1、开放地址法：在发生哈希碰撞时，通过一定的算法在哈希表中寻找一个空闲的位置，并将元素插入该位置。

2、链式哈希表：在每个哈希表的元素位置上，存储一个链表，哈希碰撞时，将元素插入到相应的链表中。

3、再哈希法：如果一个哈希函数产生的哈希值发生了碰撞，就再次使用另一个哈希函数计算哈希值。

4、负载因子调整：通过调整哈希表的容量、负载因子等参数，可以减少哈希碰撞的发生。

九、HashMap为什么线程不安全

HashMap线程安全吗？为什么？

HashMap是非线程安全的。在多线程环境下，如果多个线程同时修改HashMap中的数据，就可能会导致数据的不一致性。

说白了就是没加锁。

当多个线程同时调用HashMap的put()方法，一旦他们计算出的hash值相同，就会发生冲突，导致数据被覆盖。

所以，对于多线程并发访问的情况，建议使用线程安全的Map实现。

例如ConcurrentHashMap，或者使用Collections.synchronizedMap()方法将HashMap包装成一个线程安全的Map。

十、HashMap、HashTable、ConcurrentHashMap的区别

最后一个问题：说一下HashMap、HashTable、ConcurrentHashMap的区别？

麻了! 真的麻了....救救孩子吧....

HashMap、HashTable、ConcurrentHashMap都是Java中常用的哈希表实现。

区别主要在以下几个方面：

1、线程安全性：HashTable是线程安全的，HashMap是非线程安全的，ConcurrentHashMap通过分段锁的方式保证了线程安全。

2、是否可为空：HashTable不允许value为空，ConcurrentHashMap不允许null值作为key或value，而HashMap则允许null作为key或value。

3、迭代器：HashTable的迭代器是通过Enumeration实现的，而HashMap和ConcurrentHashMap使用的是Iterator实现的。

4、扩容：HashTable在扩容时，将容量扩大一倍加一，而HashMap和ConcurrentHashMap的扩容机制是将容量扩大一倍。

5、初始容量：HashTable的初始容量为11，而HashMap和ConcurrentHashMap的初始容量为16。

6、性能：HashMap通常比HashTable性能更好，因为它没加锁。所以弊端就是线程不安全。但后者加了锁，是线程安全的，缺点就是消耗性能。ConcurrentHashMap在多线程并发访问时，比HashTable和HashMap性能更好，因为它使用了分段锁来保证线程安全。

所以，不建议使用HashTable。至于选择HashMap还是ConcurrentHashMap取决于并发访问量的大小，若并发访问量不高，则选用HashMap。若并发访问量较大，则选用ConcurrentHashMap。

ok，那今天先到这里吧。练习时长两年半的程序员.....唱跳rap篮球🏀....差点就遭老罪喽～

还有，别忘记给那个练习时长两年半的三婶儿也点个赞哈～她唱跳rap篮球也还行......

在 Spring Boot 出现之前，我们要运行一个 Java Web 应用，首先需要有一个 Web 容器（例如 Tomcat 或 Jetty），然后将我们的 Web 应用打包后放到容器的相应目录下，最后再启动容器。

在 IDE 中也需要对 Web 容器进行一些配置，才能够运行或者 Debug。而使用 Spring Boot 我们只需要像运行普通 JavaSE 程序一样，run 一下 main() 方法就可以启动一个 Web 应用了。这是怎么做到的呢？今天我们就一探究竟，分析一下 Spring Boot 的启动流程。

概览

回看我们写的第一个 Spring Boot 示例，我们发现，只需要下面几行代码我们就可以跑起一个 Web 服务器：

@SpringBootApplication

public class HelloApplication {

	public static void main(String[] args) {

		SpringApplication.run(HelloApplication.class, args);

	}

}

去掉类的声明和方法定义这些样板代码，核心代码就只有一个 @SpringBootApplication 注解和 SpringApplication.run(HelloApplication.class, args) 了。而我们知道注解相当于是一种配置，那么这个 run() 方法必然就是 Spring Boot 的启动入口了。

接下来，我们沿着 run() 方法来顺藤摸瓜。进入 SpringApplication 类，来看看 run() 方法的具体实现：

public class SpringApplication {

	......

	public ConfigurableApplicationContext run(String... args) {

		// 1 应用启动计时开始

		StopWatch stopWatch = new StopWatch();

		stopWatch.start();

		

		// 2 声明上下文

		DefaultBootstrapContext bootstrapContext = createBootstrapContext();

		ConfigurableApplicationContext context = null;

		

		// 3 设置 java.awt.headless 属性

		configureHeadlessProperty();

		

		// 4 启动监听器

		SpringApplicationRunListeners listeners = getRunListeners(args);

		listeners.starting(bootstrapContext, this.mainApplicationClass);

		try {

			// 5 初始化默认应用参数

			ApplicationArguments applicationArguments = new DefaultApplicationArguments(args);

			

			// 6 准备应用环境

			ConfigurableEnvironment environment = prepareEnvironment(listeners, bootstrapContext, applicationArguments);

			configureIgnoreBeanInfo(environment);

			

			// 7 打印 Banner（Spring Boot 的 LOGO）

			Banner printedBanner = printBanner(environment);

			

			// 8 创建上下文实例

			context = createApplicationContext();

			context.setApplicationStartup(this.applicationStartup);

			

			// 9 构建上下文

			prepareContext(bootstrapContext, context, environment, listeners, applicationArguments, printedBanner);

			

			// 10 刷新上下文

			refreshContext(context);

			

			// 11 刷新上下文后处理

			afterRefresh(context, applicationArguments);

			

			// 12 应用启动计时结束

			stopWatch.stop();

			if (this.logStartupInfo) {

				// 13 打印启动时间日志

				new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);

			}

			

			// 14 发布上下文启动完成事件

			listeners.started(context);

			

			// 15 调用 runners

			callRunners(context, applicationArguments);

		}

		catch (Throwable ex) {

			// 16 应用启动发生异常后的处理

			handleRunFailure(context, ex, listeners);

			throw new IllegalStateException(ex);

		}



		try {

			// 17 发布上下文就绪事件

			listeners.running(context);

		}

		catch (Throwable ex) {

			handleRunFailure(context, ex, null);

			throw new IllegalStateException(ex);

		}

		return context;

	}

	......

}

Spring Boot 启动时做的所有操作都这这个方法里面，当然在调用上面这个 run() 方法之前，还创建了一个 SpringApplication 的实例对象。因为上面这个 run() 方法并不是一个静态方法，所以需要一个对象实例才能被调用。

可以看到，方法的返回值类型为 ConfigurableApplicationContext，这是一个接口，我们真正得到的是 AnnotationConfigServletWebServerApplicationContext 的实例。通过类名我们可以知道，这是一个基于注解的 Servlet Web 应用上下文（我们知道上下文（context）是 Spring 中的核心概念）。

上面对于 run() 方法中的每一个步骤都做了简单的注释，接下来我们选择几个比较有代表性的来详细分析。

应用启动计时

在 Spring Boot 应用启动完成时，我们经常会看到类似下面内容的一条日志：

Started AopApplication in 2.732 seconds (JVM running for 3.734)

应用启动后，会将本次启动所花费的时间打印出来，让我们对于启动的速度有一个大致的了解，也方便我们对其进行优化。记录启动时间的工作是 run() 方法做的第一件事，在编号 1 的位置由 stopWatch.start() 开启时间统计，具体代码如下：

public void start(String taskName) throws IllegalStateException {

    if (this.currentTaskName != null) {

        throw new IllegalStateException("Can't start StopWatch: it's already running");

    }

    // 记录启动时间

    this.currentTaskName = taskName;

    this.startTimeNanos = System.nanoTime();

}

然后到了 run() 方法的基本任务完成的时候，由 stopWatch.stop()（编号 12 的位置）对启动时间做了一个计算，源码也很简单：

public void stop() throws IllegalStateException {

    if (this.currentTaskName == null) {

        throw new IllegalStateException("Can't stop StopWatch: it's not running");

    }

    // 计算启动时间

    long lastTime = System.nanoTime() - this.startTimeNanos;

    this.totalTimeNanos += lastTime;

    ......

}

最后，在 run() 中的编号 13 的位置将启动时间打印出来：

if (this.logStartupInfo) {

    // 打印启动时间

   new StartupInfoLogger(this.mainApplicationClass).logStarted(getApplicationLog(), stopWatch);

}

打印 Banner

Spring Boot 每次启动是还会打印一个自己的 LOGO，如图：

这种做法很常见，像 Redis、Docker 等都会在启动的时候将自己的 LOGO 打印出来。Spring Boot 默认情况下会打印那个标志性的“树叶”和 “Spring” 的字样，下面带着当前的版本。

在 run() 中编号 7 的位置调用打印 Banner 的逻辑，最终由 SpringBootBanner 类的 printBanner() 完成。这个图案定义在一个常量数组中，代码如下：

class SpringBootBanner implements Banner {



    private static final String[] BANNER = {

            "", 

            "  .   ____          _            __ _ _",

            " /\\\\ / ___'_ __ _ _(_)_ __  __ _ \\ \\ \\ \\", 

            "( ( )\\___ | '_ | '_| | '_ \\/ _` | \\ \\ \\ \\",

            " \\\\/  ___)| |_)| | | | | || (_| |  ) ) ) )", 

            "  '  |____| .__|_| |_|_| |_\\__, | / / / /",

            " =========|_|==============|___/=/_/_/_/" 

    };

    ......

        

	public void printBanner(Environment environment, Class sourceClass, PrintStream printStream) {

		for (String line : BANNER) {

			printStream.println(line);

		}

		......

	}



}

手工格式化了一下 BANNER 的字符串，轮廓已经清晰可见了。真正打印的逻辑就是 printBanner() 方法里面的那个 for 循环。

记录启动时间和打印 Banner 代码都非常的简单，而且都有很明显的视觉反馈，可以清晰的看到结果。拿出来咱们做个热身，配合断点去 Debug 会有更加直观的感受，尤其是打印 Banner 的时候，可以看到整个内容被一行一行打印出来，让我想起了早些年用那些配置极低的电脑（还是 CRT 显示器）运行着 Win98，经常会看到屏幕内容一行一行加载显示。

创建上下文实例

下面我们来到 run() 方法中编号 8 的位置，这里调用了一个 createApplicationContext() 方法，该方法最终会调用 ApplicationContextFactory 接口的代码：

ApplicationContextFactory DEFAULT = (webApplicationType) -> {

    try {

        switch (webApplicationType) {

            case SERVLET:

                return new AnnotationConfigServletWebServerApplicationContext();

            case REACTIVE:

                return new AnnotationConfigReactiveWebServerApplicationContext();

            default:

                return new AnnotationConfigApplicationContext();

        }

    }

    catch (Exception ex) {

        throw new IllegalStateException("Unable create a default ApplicationContext instance, "

                                        + "you may need a custom ApplicationContextFactory", ex);

    }

};

这个方法就是根据 SpringBootApplication 的 webApplicationType 属性的值，利用反射来创建不同类型的应用上下文（context）。而属性 webApplicationType 的值是在前面执行构造方法的时候由 WebApplicationType.deduceFromClasspath() 获得的。通过方法名很容易看出来，就是根据 classpath 中的类来推断当前的应用类型。

我们这里是一个普通的 Web 应用，所以最终返回的类型为 SERVLET。所以会返回一个 AnnotationConfigServletWebServerApplicationContext 实例。

构建容器上下文

接着我们来到 run() 方法编号 9 的 prepareContext() 方法。通过方法名，我们也能猜到它是为 context 做上台前的准备工作的。

private void prepareContext(DefaultBootstrapContext bootstrapContext, ConfigurableApplicationContext context,

                            ConfigurableEnvironment environment, SpringApplicationRunListeners listeners,

                            ApplicationArguments applicationArguments, Banner printedBanner) {

    ......

    // 加载资源

    load(context, sources.toArray(new Object[0]));

    listeners.contextLoaded(context);

}

在这个方法中，会做一些准备工作，包括初始化容器上下文、设置环境、加载资源等。

加载资源

上面的代码中，又调用了一个很关键的方法——load()。这个 load() 方法真正的作用是去调用 BeanDefinitionLoader 类的 load() 方法。源码如下：

class BeanDefinitionLoader {

    ......

    void load() {

        for (Object source : this.sources) {

            load(source);

        }

	}



	private void load(Object source) {

		Assert.notNull(source, "Source must not be null");

		if (source instanceof Class) {

			load((Class) source);

			return;

		}

		if (source instanceof Resource) {

			load((Resource) source);

			return;

		}

		if (source instanceof Package) {

			load((Package) source);

			return;

		}

		if (source instanceof CharSequence) {

			load((CharSequence) source);

			return;

		}

		throw new IllegalArgumentException("Invalid source type " + source.getClass());

	}

    ......

}

可以看到，load() 方法在加载 Spring 中各种资源。其中我们最熟悉的就是 load((Class) source) 和 load((Package) source) 了。一个用来加载类，一个用来加载扫描的包。

load((Class) source) 中会通过调用 isComponent() 方法来判断资源是否为 Spring 容器管理的组件。 isComponent() 方法通过资源是否包含 @Component 注解（@Controller、@Service、@Repository 等都包含在内）来区分是否为 Spring 容器管理的组件。

而 load((Package) source) 方法则是用来加载 @ComponentScan 注解定义的包路径。

刷新上下文

run() 方法编号10 的 refreshContext() 方法是整个启动过程比较核心的地方。像我们熟悉的 BeanFactory 就是在这个阶段构建的，所有非懒加载的 Spring Bean（@Controller、@Service 等）也是在这个阶段被创建的，还有 Spring Boot 内嵌的 Web 容器要是在这个时候启动的。

跟踪源码你会发现内部调用的是 ConfigurableApplicationContext.refresh()，ConfigurableApplicationContext 是一个接口，真正实现这个方法的有三个类：AbstractApplicationContext、ReactiveWebServerApplicationContext 和 ServletWebServerApplicationContext。

AbstractApplicationContext 为后面两个的父类，两个子类的实现比较简单，主要是调用父类实现，比如 ServletWebServerApplicationContext 中的实现是这样的：

public final void refresh() throws BeansException, IllegalStateException {

   try {

      super.refresh();

   }

   catch (RuntimeException ex) {

      WebServer webServer = this.webServer;

      if (webServer != null) {

         webServer.stop();

      }

      throw ex;

   }

}

主要的逻辑都在 AbstractApplicationContext 中：

@Override

public void refresh() throws BeansException, IllegalStateException {

	synchronized (this.startupShutdownMonitor) {

		StartupStep contextRefresh = this.applicationStartup.start("spring.context.refresh");



		// 1 准备将要刷新的上下文

		prepareRefresh();



		// 2 （告诉子类，如：ServletWebServerApplicationContext）刷新内部 bean 工厂

		ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();



		// 3 为上下文准备 bean 工厂

		prepareBeanFactory(beanFactory);



		try {

			// 4 允许在子类中对 bean 工厂进行后处理

			postProcessBeanFactory(beanFactory);



			StartupStep beanPostProcess = this.applicationStartup.start("spring.context.beans.post-process");

			// 5 调用注册为 bean 的工厂处理器

			invokeBeanFactoryPostProcessors(beanFactory);



			// 6 注册拦截器创建的 bean 处理器

			registerBeanPostProcessors(beanFactory);

			beanPostProcess.end();



			// 7 初始化国际化相关资源

			initMessageSource();



			// 8 初始化事件广播器

			initApplicationEventMulticaster();



			// 9 为具体的上下文子类初始化特定的 bean

			onRefresh();



			// 10 注册监听器

			registerListeners();



			// 11 实例化所有非懒加载的单例 bean

			finishBeanFactoryInitialization(beanFactory);



			// 12 完成刷新发布相应的事件（Tomcat 就是在这里启动的）

			finishRefresh();

		}



		catch (BeansException ex) {

			if (logger.isWarnEnabled()) {

				logger.warn("Exception encountered during context initialization - " +

						"cancelling refresh attempt: " + ex);

			}



			// 遇到异常销毁已经创建的单例 bean

			destroyBeans();



			// 充值 active 标识

			cancelRefresh(ex);



			// 将异常向上抛出

			throw ex;

        } finally {

            // 重置公共缓存，结束刷新

            resetCommonCaches();

            contextRefresh.end();

        }

    }

}

简单说一下编号 9 处的 onRefresh() 方法，该方法父类未给出具体实现，需要子类自己实现，ServletWebServerApplicationContext 中的实现如下：

protected void onRefresh() {

   super.onRefresh();

   try {

      createWebServer();

   }

   catch (Throwable ex) {

      throw new ApplicationContextException("Unable to start web server", ex);

   }

}



private void createWebServer() {

   ......

   if (webServer == null && servletContext == null) {

      ......

      

      // 根据配置获取一个 web server（Tomcat、Jetty 或 Undertow）

      ServletWebServerFactory factory = getWebServerFactory();

      this.webServer = factory.getWebServer(getSelfInitializer());

      ......

   }

   ......

}

factory.getWebServer(getSelfInitializer()) 会根据项目配置得到一个 Web Server 实例，这里跟下一篇将要谈到的自动配置有点关系。

前言

在大学的时候，学校一般只会教你你写编程语言，比如C、C++、JAVA等编程语言。但是当你离开大学进入这个行业开始工作时，才知道编程不只是知道编程语言、语法等，要想写好代码，必须还要了解一些编程原则才行。本文主要讨论KISS、DRY和SOLID这些常见的编程原则，而且你会发现随着工作时间越久，越能感受这些编程原则的精妙之处，历久弥香。

KISS原则

Keep It Simple, Stupid!

你是不是有过接手同事的代码感到十分头疼的经历，明明可以有更加简单、明白的写法，非要绕来绕去，看不明白？

其实，我们在写代码的时候应该要遵守KISS原则，核心思想就是尽量保持简单。代码的可读性和可维护性是衡量代码质量非常重要的两个标准。而 KISS 原则就是保持代码可读和可维护的重要手段。代码足够简单，也就意味着很容易读懂，bug 比较难隐藏。即便出现 bug，修复起来也比较简单。

我们写代码的的时候要站在别人的角度出发，就像马丁·福勒说的，我们写的代码不是给机器看的，而是给人看的。

“任何傻瓜都可以编写计算机可以理解的代码。优秀的程序员编写出人类可以理解的代码。” — 马丁·福勒

那么如何才能写出满足KISS原则的代码呢？

如何写出KISS原则的代码？

我们直接上例子，下面的校验IP是否合法的3种实现方式，大家觉得哪个最KISS?

1. 写法一

2. 写法二

3. 写法三

• 写法一代码量最少，正则表达式本身是比较复杂的，写出完全没有 bug 的正则表达本身就比较有挑战；另一方面，并不是每个程序员都精通正则表达式。对于不怎么懂正则表达式的同事来说，看懂并且维护这段正则表达式是比较困难的。这种实现方式会导致代码的可读性和可维护性变差，所以，从 KISS 原则的设计初衷上来讲，这种实现方式并不符合 KISS 原则。


• 写法二使用了 StringUtils 类、Integer 类提供的一些现成的工具函数，来处理 IP地址字符串，逻辑清晰，可读性好。


• 写法三不使用任何工具函数，而是通过逐一处理 IP 地址中的字符，来判断是否合法，容易出bug，不好理解。

所以说，符合KISS原则的代码并不是代码越少越好，还要考虑代码是否逻辑清晰、是否容易理解、是否够稳定。

总结以下如何写出KISS原则的代码：

1. 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。


2. 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出bug 的概率会更高，维护的成本也比较高。


3. 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。


4. 主观站在别人的角度上编写代码。你在编写代码的时候就要思考我这个同事看这段代码是不是很快就能够明白理解。

DRY原则

Don't Repeat Yourself

你是不是有过这样的经历，项目中很多重复逻辑的代码，然后修改一个地方，另外一个地方忘记修改，导致测试给你提了很多bug？

DRY原则，英文全称Don’t Repeat Yourself，直译过来就是不要重复你自己。这里的重复不仅仅是代码一模一样，还包括实现逻辑重复、功能语义重复、代码执行重复等。我们不要偷懒，有责任把这些存在重复的地方识别出来，然后优化它们。

如何写出DRY原则的代码呢？

我们直接上例子，代码重复的我就不讲了，很好理解，关于实现逻辑或者功能语义重复的我觉个例子。

还是上面校验IP的例子，团队中两个同事由于不知道就有了两种写法。

• 同事A写法

• 同事B写法

尽管两段代码的实现逻辑不重复，但语义重复，也就是功能重复，我们认为它违反了 DRY 原则。我们应该在项目中，统一一种实现思路，所有用到判断 IP 地址是否合法的地方，都统一调用同一个函数。不然哪天校验规则变了，很容易只改了其中一个，另外一个漏改，就会出现莫名其妙的bug。

其他的比如逻辑重复的意思是虽然功能是不一致的，但是里面的逻辑都是一模一样的。举个例子，比如校验用户名和校验密码，虽然功能不一致，但是校验逻辑都是相似，判空、字符长度等等，这种情况我们就需要把相似的逻辑抽取到一个方法中，不然也是不符合DRY原则。

那么我们平时写代码注意些什么才是符合DRY原则呢？

• 使用现成的轮子，不轻易造轮子

其实最关键的就是写代码带脑子，用到一个方法先看看有没有现成的，不要看看不看，就动手在那里造轮子。

• 减少代码耦合

对于高度耦合的代码，当我们希望复用其中的一个功能，想把这个功能的代码抽取出来成为一个独立的模块、类或者函数的时候，往往会发现牵一发而动全身。移动一点代码，就要牵连到很多其他相关的代码。所以，高度耦合的代码会影响到代码的复用性，我们要尽量减少代码耦合。

• 满足单一职责原则

我们前面讲过，如果职责不够单一，模块、类设计得大而全，那依赖它的代码或者它依赖的代码就会比较多，进而增加了代码的耦合。根据上一点，也就会影响到代码的复用性。相反，越细粒度的代码，代码的通用性会越好，越容易被复用。

• 模块化

这里的“模块”，不单单指一组类构成的模块，还可以理解为单个类、函数。我们要善于将功能独立的代码，封装成模块。独立的模块就像一块一块的积木，更加容易复用，可以直接拿来搭建更加复杂的系统。

• 业务与非业务逻辑分离

越是跟业务无关的代码越是容易复用，越是针对特定业务的代码越难复用。所以，为了复用跟业务无关的代码，我们将业务和非业务逻辑代码分离，抽取成一些通用的框架、类库、组件等。

• 通用代码下沉

从分层的角度来看，越底层的代码越通用、会被越多的模块调用，越应该设计得足够可复用。一般情况下，在代码分层之后，为了避免交叉调用导致调用关系混乱，我们只允许上层代码调用下层代码及同层代码之间的调用，杜绝下层代码调用上层代码。所以，通用的代码我们尽量下沉到更下层。

• 继承、多态、抽象、封装

在讲面向对象特性的时候，我们讲到，利用继承，可以将公共的代码抽取到父类，子类复用父类的属性和方法。利用多态，我们可以动态地替换一段代码的部分逻辑，让这段代码可复用。除此之外，抽象和封装，从更加广义的层面、而非狭义的面向对象特性的层面来理解的话，越抽象、越不依赖具体的实现，越容易复用。代码封装成模块，隐藏可变的细节、暴露不变的接口，就越容易复用。

• 应用模板等设计模式

一些设计模式，也能提高代码的复用性。比如，模板模式利用了多态来实现，可以灵活地替换其中的部分代码，整个流程模板代码可复用。

SOLID原则

SOLID原则不是一个单一的原则，而是对软件开发至关重要的 5 条原则，遵循这些原则有助于我们写出高内聚、低耦合、可扩展、可维护性好的代码。

S—单一职责原则

一个类应该有一个，而且只有一个改变它的理由。

单一职责原则在我看来是最容易理解也是最重要的一个原则。它的核心思想就是一个模块、类或者方法只做一件事，只有一个职责，千万不要越俎代庖。它可以带来下面的好处：

• 可以让代码耦合度更低


• 使代码更容易理解和维护


• 使代码更易于测试和维护，使软件更易于实施，并有助于避免未来更改的意外副作用

举个例子，我们有两个类Person和Account。 两者都负有存储其特定信息的单一责任。 如果要更改Person的状态，则无需修改类Account，反之亦然， 不要把账户的行为比如修改账户名changeAcctName写在Person类中。

    public class Person {

    	private Long personId;

    	private String firstName;

    	private String lastName;

    	private String age;

    	private List accounts;



        // 错误做法

        public void changeAcctName(Account account, String acctName) {

            acccount.setAccountName(acctName);

            // 更新到数据库

        }

    }



    public class Account {

    	private Long guid;

    	private String accountNumber;

    	private String accountName;

    	private String status;

    	private String type;



    }

所以大家在编写代码的时候，一定要停顿思考下这个段代码真的写在这里吗？另外很关键的一点是如果发现一个类或者一个方法十分庞大，那么很有可能已经违背单一职责原则了，后续维护可想而知十分痛苦。

O—开闭原则

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

对扩展开放，对修改关闭，什么意思？很简单，其实就是我们要尽量通过新增类实现功能，而不是修改原有的类或者逻辑。因为修改已有代码很有可能对已有功能引入bug。

让我们通过一个例子来理解这个原则，比如一个通知服务。

    public class NotificationService {

    	public void sendOTP(String medium) {

            if (medium.equals("email")) {

                //email 发送

            } else if (medium.equals("mobile")) {

                // 手机发送

        	} 

    }

现在需要新增微信的方式通知，你要怎么做呢? 是在加一个if else吗？ 这样就不符合开闭原则了，我们看下开闭原则该怎么写。

• 定义一个通知服务接口

    public interface NotificationService {

    	public void sendOTP();

    }

• E-mail方式通知类EmailNotification

    public class EmailNotification implements NotificationService{

    	public void sendOTP(){

    		// write Logic using JavaEmail api

    	}

    }

• 手机方式通知类MobileNotification

    public class MobileNotification implements NotificationService{

        public void sendOTP(){

    		// write Logic using Twilio SMS API

    	}

    }

• 同样可以添加微信通知服务的实现WechatNotification

    public class WechatNotification implements NotificationService{

    	public void sendOTP(String medium){

    		// write Logic using wechat API

    	}

    }

这样的方式就是遵循开闭原则的，你不用修改核心的业务逻辑，这样可能带来意向不到的后果，而是扩展实现方式，由调用方根据他们的实际情况调用。

是不是想到了设计模式中的策略模式，其实设计模式就是指导我们写出高内聚、低耦合的代码。

L—里氏替换原则

派生类或子类必须可替代其基类或父类

这个原则稍微有点难以理解，它的核心思想是每个子类或派生类都应该可以替代/等效于它们的基类或父类。这样有一个好处，就是无论子类是什么类型，客户端通过父类调用都不会产生意外的后果。

理解不了？那我我们通过一个例子来理解一下。

让我们考虑一下我有一个名为 SocialMedia 的抽象类，它支持所有社交媒体活动供用户娱乐，如下所示：

    package com.alvin.solid.lsp;



    public abstract class SocialMedia {

        

        public abstract  void chatWithFriend();

        

        public abstract void publishPost(Object post);

        

        public abstract  void sendPhotosAndVideos();

        

        public abstract  void groupVideoCall(String... users);

    }

社交媒体可以有多个实现或可以有多个子类，如 Facebook、Wechat、Weibo 和 Twitter 等。

现在让我们假设 Facebook 想要使用这个特性或功能。

    package com.alvin.solid.lsp;



    public class Wechat extends SocialMedia {



        public void chatWithFriend() {

            //logic  

        }



        public void publishPost(Object post) {

            //logic  

        }



        public void sendPhotosAndVideos() {

            //logic  

        }



        public void groupVideoCall(String... users) {

            //logic  

        }

    }

我们都知道Facebook都提供了所有上述的功能，所以这里我们可以认为Facebook是SocialMedia类的完全替代品，两者都可以无中断地替代。

现在让我们讨论 Weibo 类

    package com.alvin.solid.lsp;



    public class Weibo extends SocialMedia {

        public void chatWithFriend() {

            //logic

        }



        public void publishPost(Object post) {

          //logic

        }



        public void sendPhotosAndVideos() {

          //logic

        }



        public void groupVideoCall(String... users) {

            //不适用

        }

    }

我们都知道Weibo微博这个产品是没有群视频功能的，所以对于 groupVideoCall方法来说 Weibo 子类不能替代父类 SocialMedia。所以我们认为它是不符合里式替换原则。

如果强行这么做的话，会导致客户端用父类SocialMedia调用，但是实现类注入的可能是个Weibo的实现，调用groupVideoCall行为，产生意想不到的后果。

那有什么解决方案吗？

那就把功能拆开呗。

    public interface SocialMedia {   

       public void chatWithFriend(); 

       public void sendPhotosAndVideos() 

    }

    public interface SocialPostAndMediaManager { 

        public void publishPost(Object post); 

    }

    public interface VideoCallManager{ 

       public void groupVideoCall(String... users); 

    }

现在，如果您观察到我们将特定功能隔离到单独的类以遵循LSP。

现在由实现类决定支持功能，根据他们所需的功能，他们可以使用各自的接口，例如 Weibo 不支持视频通话功能，因此 Weibo 实现可以设计成这样：

    public class Instagram implements SocialMedia,SocialPostAndMediaManager{

    	public void chatWithFriend(){

        //logic

        }

        public void sendPhotosAndVideos(){

        //logic

        }

        public void publishPost(Object post){

        //logic

        }

    }

这样子就是符合里式替换原则LSP。

I—接口隔离原则

接口不应该强迫他们的客户依赖它不使用的方法。

大家可以看看自己的工程，是不是一个接口类中有很多很多的接口，每次调用API方法的时候IDE工具给你弹出一大堆，十分的"臃肿肥胖"。所以该原则的核心思想要将你的接口拆小，拆细，打破”胖接口“，不用强迫客户端实现他们不需要的接口。是不是和单一职责原则有点像？

例如，假设有一个名为 UPIPayment 的接口，如下所示

    public interface UPIPayments {

        

        public void payMoney();

        

        public void getScratchCard();

        

        public void getCashBackAsCreditBalance();

    }

现在让我们谈谈 UPIPayments 的一些实现，比如 Google Pay 和 AliPay。

Google Pay 支持这些功能所以他可以直接实现这个 UPIPayments 但 AliPay 不支持 getCashBackAsCreditBalance() 功能所以这里我们不应该强制客户端 AliPay 通过实现 UPIPayments 来覆盖这个方法。

我们需要根据客户需要分离接口，所以为了满足接口隔离原则，我们可以如下设计：

• 创建一个单独的接口来处理现金返还。

    public interface CashbackManager{ 

    	public void getCashBackAsCreditBalance(); 

    }

现在我们可以从 UPIPayments 接口中删除getCashBackAsCreditBalance ，AliPay也不需要实现getCashBackAsCreditBalance()这个它没有的方法了。

D—依赖倒置原则

高层模块不应该依赖低层模块，两者都应该依赖于抽象(接口)。抽象不应该依赖于细节(具体实现)，细节应该取决于抽象。

这个原则我觉得也不是很好理解，所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层。比如大家都知道的MVC模式，controller是调用service层接口这个抽象，而不是实现类。这也是我们经常说的要面向接口编程，而非细节或者具体实现，因为接口意味着契约，更加稳定。

我们通过一个例子加深一下理解。

• 借记卡

    public class DebitCard { 

    	public void doTransaction(int amount){ 

            System.out.println("tx done with DebitCard"); 

        } 

    }

• 信用卡

    public class CreditCard{ 

    	public void doTransaction(int amount){ 

            System.out.println("tx done with CreditCard"); 

        } 

    }

现在用这两张卡你去购物中心购买了一些订单并决定使用信用卡支付

    public class ShoppingMall {

    	private DebitCard debitCard;

    	public ShoppingMall(DebitCard debitCard) {

            this.debitCard = debitCard;

       	}

    	public void doPayment(Object order, int amount){              

            debitCard.doTransaction(amount); 

     	}

    	public static void main(String[] args) {

         	DebitCard debitCard=new DebitCard();

         	ShoppingMall shoppingMall=new ShoppingMall(debitCard);

         	shoppingMall.doPayment("some order",5000);

        }

    }

上面的做法是一个错误的方式，因为 ShoppingMall 类与 DebitCard 紧密耦合。

现在你的借记卡余额不足，想使用信用卡，那么这是不可能的，因为 ShoppingMall 与借记卡紧密结合。

当然你也可以这样做，从构造函数中删除借记卡并注入信用卡。但这不是一个好的方式，它不符合依赖倒置原则。

那该如何正确设计呢？

• 定义依赖的抽象接口BankCard

    public interface BankCard { 

      public void doTransaction(int amount); 

    }