可以给线程指定异常处理类来捕获异常进行自定义处理。
线程中的异常可通过线程组异常处理来实现异常传递，线程组 ThreadGroup 实现了 Thread.UncaughtExceptionHandler 接口。
模版方法模式是非常常见的模式，并且用户往往使用了模板方法模式而没意思到自己已经使用了这个模式。模板方法模式是行为模式。
生活中在做某些事情时，往往存在重复的步骤，例如用户银行办事，有要办存款，办取款等，但都需要经过 取号，填单，排队，等叫号这些步骤，这些重复的步骤延伸到软件设计里就可以对其进行抽象，在抽象类里定义流程或格式（方法的调用方式（步骤的顺序）），子类继承并且可按需重写方法（步骤）。例如，简历模板，论文模板等。
在现实生活中，经常出现两个对象因接口不兼容而不能在一起工作的实例，这时需要第三者进行适配（转换）。例如，使用电脑电源适配器将220V家用电转换为电脑需要的电。
在软件设计中，也可能出现需要的功能在现有的组件库中已存在，但与现有系统并不兼容，这时使用适配器模式就可以将并不兼容的接口转换为客户希望的目标接口。
使用适配器模式来处理像货物的包装过程，被包装的货物的真实样子被包装所掩盖和改变，因此也被叫做包装（Wrapper）模式。
负载均衡（Load Balance）：指将负载（工作任务）进行均衡，分摊到多个处理节点上。负载均衡是一个统一的流量入口节点，映射了多个处理请求的映节点，入口节点将请求任务分发到不同的处理节点，实现分治。
互联网应用服务为了能满足大流量请求处理，通常会集群部署，使用负载均衡来分担单台服务器的压力，避免单点故障。
生活或工作中经常会遇到一种情境，即要完成或处理某件任务时，需要经过层层传递到某一层级才能得到处理。
例如，加薪审批，直接的小组长可能并没有权限，需要向上报批，可能需要经过好几层到副总级别才得到处理。例如，击鼓传花游戏，花在多个人之间传递把大家连接起来，鼓声落，谁持有花谁就喝酒。
这种情境在软件设计中也是存在的，多个对象之间相互引用而形成一条链，最终链中的某一个对象处理了任务，而客户端并不需要知道具体是谁处理的，对象也不需要知道任务具体来自谁， 这就是责任链的最简单模型。
状态机由基于事件或计时器的触发器驱动。可以通过发送事件、监听状态机的操作或请求当前状态来与状态机交互。
Spring Statemachine 是 Spring 提供的将状态机应用于 Spring 应用程序的框架。可以与 Spring IoC 无缝集成，可将 Bean 与状态机关联。
做软件开发的，经常会碰到流程性的业务需求，最常见的是工作流类型的需求。例如审批流程，下单支付流程。每个节点的每个状态分别由有相应权限的角色人处理。
实现流程性业务需求，通常会使用工作流引擎或使用状态流的方式来实现。常见的开源的工作流引擎有 Activity，Flowable。
项目可能会有多个数据源，例如读写分离至少有两个数据库，或一个主库多个从库，或一个系统里面不同业务拆分有各自的数据库，在使用时需要确定使用正确的数据源。
Spring 多数据源实现方式大概有2种，一种是新建多个 MapperScan 扫描不同 Mapper 包，另一种是继承 AbstractRoutingDataSource 实现动态路由。
本篇是基于 Spring AOP 实现数据源动态路由，多个 MapperScan 扫描不同的 Mapper 包的方式可参考 Spring Boot 2实践系列(三十九)：Spring Boot 2.x + Mybatis + Druid + Common Mapper 配置多数据源
在实际开发中，可能需要打印方法的入参和返回的数据以帮助出现问题时可快递定位.
常规的做法在方法中的业务处理之前使用 Logger 打印方法入参，在业务处理之后打印结果数据，这样就会在很多方法中存在重复代码。
像打印日志这类跨多个业务和模块的需求，可以通过 Spring AOP 来统一实现，完全省略了方法中手动添加 Logger 的操作。
Aspect-oriented Programming (AOP：面向切面编程) 提供另一种思考程序结构的方式来补充(增强) 面向对象编程（OOP）。
OOP 中模块化的关键单元是类，倾向于采用封装、继承、多态等概念，将一个个的功能在对象中来实现。而在 AOP 中模块化的单元是 切面，切面使关注点（例如事务管理）模块化，可以跨越多种类型和对象。
Spring AOP 框架是 Spring 的核心组件之一。Spring IoC 容器不依赖于 AOP，但 AOP 是对 Spring IoC 的补充，以提供功能强大的中间件解决方案。