看网课的一些笔记 📝

持久化之RDB 💿

RDB (Redis DataBase)

是什么

redis会单独fork一个子进程来进行持久化, 会先将数据写入到一个临时文件中, 待持久化过程结束了, 再用这个临时文件替换上次持久化好的文件.
整个过程, 主进程不进行任何IO操作, 这就确保了极高的性能.
如果需要进行大规模数据的恢复, 且对数据回复的完整性不是特别敏感, RDB比AOF方式更加高效, RDB的缺点是最后一次持久化后的数据可能丢失

fork的作用是复制一个与当前进程一样的进程. 新进程的所有数据(变量, 环境变量, 程序计数器等), 数值都和原进程一样, 但是一个全新的进程, 并作为原进程的子进程

RDB保存的是dump.rdb文件

配置位置

如何触发rdb快照

• 配置文件中的默认快照配置 => 冷拷贝后重新使用 cp dump.rdb dump_new.rdb
• save/bgsave命令
  • save 只管保存, 全部阻塞
  • bgsave 会在后台异步进行快照操作, 快照同时还可以响应客户端请求. 可以通过lastsave命令获取最后一次成功执行快照的时间
• 执行flushall命令, 会产生空的dump.rdb, 无意义

如何恢复

• 将dump.rdb移动到redis安装目录并启动服务即可
• config get dir 获取安装目录

优劣势

优势: 😊

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高

劣势: 😔

• 在一定时间间隔内做一次备份, 可能丢失最后一次快照的修改
• fork的时候, 内存中的数据被复制了一份, 要占用大致两倍空间

持久化之AOF 📀

AOF (Append Only File)

是什么

以日志的形式来记录每个写操作, 将redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据, redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF保存的是appendonly.aof文件

rdb和aof共存时, 先加载aof

配置位置

AOF启动/修复/恢复

• 正常恢复
  • 启动: 修改默认的appendonly no 改为 yes
  • 将有数据的aof文件复制一份到安装目录
  • 恢复: 重启redis然后重新加载
• 异常恢复
  • 启动: 修改默认的appendonly no 改为 yes
  • 备份被写坏的aof文件
  • 修复: redis-check-aof –fix 进行修复
  • 恢复: 重启redis然后重新加载

Rewrite

是什么
AOF采用文件追加的方式, 为了避免文件越来越大, 新增了重写机制, 当aof文件的大小超过所设定的阈值时, redis就会启动aof文件的内容压缩, 只保留可以恢复数据的最小指令集, 可以使用bgrewriteaof命令

重写原理
aof文件持续增长而过大时, 会fork出一条新进程来将文件重写(先写临时文件再rename). 遍历新进程内存中的数据, 为每条记录写一次set命令. 重写aof文件时, 并不会读取旧的aof文件, 而是将整个内存中的数据库内容用命令了方式重写了一个新的aof文件

触发机制
redis会记录上次重写时的aof文件大小, 默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64MB时触发

优劣势

优势: 😊

• 每修改同步: appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘, 性能较差但数据完整性比较高
• 每秒同步: appendfsync everysec 异步操作, 每秒记录 如果一秒内宕机, 有数据丢失
• 不同步: appendfsync no 从不同步

劣势: 😔

• 相同数据集的数据而言aof文件要远大于rdb文件, 恢复速度慢于rdb
• aof运行效率要慢于rdb, 每秒同步策略效率较好, 不同步效率和rdb相同

总结

事务 📋

情况一: 全体连坐 => 类比Exception

某条命令语法出错, 则事务不能执行

情况二: 冤头债主 => 类比RuntimeException

某条命令执行结果出错, 其余的命令仍能执行

因此Redis的事务仅支持部分原子性

watch命令类似于乐观锁, 通过watch命令在执行事务之前监控了多个key, 若在watch之后有任何key发生变化, exec执行的事务都将被放弃, 同时返回nullmulti-bulk应答通知调用者事务执行失败

三个特性:

1. 单独的隔离性: 事务执行过程中, 不会被其他客户端发送来的命令请求打断
2. 没有隔离级别的概念: 队列中的命令在没有提交之前都不会被执行, 因此也就不存在”事务内的查询要看到事务里的更新, 在事务外的查询不能看到”这种问题
3. 不保证原子性: redis同一个事务中如果有一条命令执行失败, 其余的命令仍然会被执行, 没有回滚

主从复制 💾

配从库不配主库 => 从库配置: slaveof 主库ip 主库端口

常用3种模式

一主N从

1. 从库能读取配置主从关系时间点之前的主库上的数据
2. 从库不能进行写命令
3. 主库关机, 从库原地待命, 主从关系不变
4. 主库重连之后的写的数据, 从库能读取到
5. 从库关机, 主从关系解除, 需要重新配置, 除非在配置文件配置主库信息

薪火相传

• 上一个slave可以是下一个slave的master, slave同样可以接收其他slaves的连接和同步请求, 可以有效减轻master的写压力
• slave中途变更指向会清除之前的数据, 重新复制最新的数据
• 配置方法: slaveof 新主库ip 新主库端口

反客为主
slaveof no one 使当前数据库停止与其他数据库的同步, 转换成主库

复制原理

• slave启动成功连接到master后会发送一个sync命令
• master接到命令启动后台的存盘进程, 同时收集所有修改数据集的命令, 在后台进程执行完毕后, master将传送整个数据文件到slave, 以完成一次完全同步
• 全量复制: slave和master建立连接后, 将master的数据全部复制
• 增量复制: master继续将后续修改命令传给slave, 完成同步. 但只要重新连接master就会自动执行一次全量复制

哨兵模式

“反客为主”的自动版, 能后台监控主库是否故障, 如果故障了根据投票数自动将从库转换为主库

如果之前的master回来, 会成为新master的slave

一组sentinel能同时监控多个master

复制不可避免有延迟问题

前端职责：
在以前传统的网站开发中，前端一般扮演的只是切图的工作，只是简单地将UI设计师提供的原型图实现成静态的HTML页面，而具体的页面交互逻辑，比如与后台的数据交互工作等，可能都是由后台的开发人员来实现的，或者是前端是紧紧的耦合后台。

后端职责：
有可能后台人员直接兼顾前端的工作，一边实现API接口，一边开发页面，两者互相切换着做，而且根据不同的url动态拼接页面，这也导致后台的开发压力大大增加。

开发模式：

方式一：

方式二：

使用技术：servlet+jsp/各种模板引擎

Servlet

我们编写java程序想要在网上实现 聊天、发帖、这样一些的交互功能，普通的java技术是很困难的。sun公司就提供了Serlvet这种技术供我们使用。它可以接收浏览器发过来的http请求，取得一些参数经过一些处理后，返回用户想要的信息。

Jsp

• JSP是一种基于文本的程序，其特点就是HTML和Java代码共同存在！
• JSP是为了简化Servlet的工作出现的替代品，Servlet输出HTML非常困难，JSP就是替代Servlet输出HTML的。
  

缺点：

1. 前端无法单独调试
2. 后端代码侵入到前端代码
   
3. jsp运行加载响应慢问题

结果：
前端紧紧的依赖后端，前后端工作分配不均。不仅仅开发效率慢，而且代码难以维护。

开发模式是，前端写好静态demo，后端拿到demo，嵌套进jsp 添加一些jsp脚本 指令 表达式用来获取后端数据并展示

半分离

步骤：

1. 浏览器请求，cdn返回html页面
2. html中的js代码以ajax方式请求后台的接口
3. 接口返回json数据，页面解析json数据，通过dom操作渲染页面

前端职责：
前端负责开发页面，通过接口（Ajax）获取数据，采用Dom操作对页面进行数据绑定，最终是由前端把页面渲染出来。

后端职责：
专注于实现业务逻辑，即使在这一时期，通常也是一个工程师搞定前后端所有工作。

使用技术：ajax dom jquery json?

Ajax

关于什么是ajax，因为它涉及到很多技术，比较难说清楚，因此主要关注一下
ajax能做什么，概况来说就是客户端与服务器，可以在【不必刷新整个浏览器】的情况下，与服务器进行异步通讯的技术

在我们之前的开发，每当用户向服务器发送请求，哪怕只是需要更新一点点的局部内容，服务器都会将整个页面进行刷新。

• 性能会有所降低(一点内容，刷新整个页面！)
• 用户的操作页面会中断(整个页面被刷新了)

ajax可以做到局部刷新，不用重新加载网页，大大提高网页加载速度和交互体验！

前端通过ajax拿到数据后就可以自由操作dom节点了。

Dom

比如一个注册页面的输入框，提示框，提交按钮等

Jquery

jquery是一个优秀的JavaScript代码库，用于高效操作dom节点

Json

一种轻量级的数据交换格式，是JavaScript的一个子集
几乎所有编程语言都有解析JSON的库，很多开发框架都提供了将一般数据转换为json格式的数据的支持，这样就可以降低前后端数据沟通成本

优点：
前端不会嵌入任何后台代码，前端专注于html、css、js的开发，不依赖于后端。自己还能够模拟json数据来渲染页面。发现bug，也能迅速定位出是谁的问题，不会出现互相推脱的现象。

缺点：

1. javascript存在大量冗余，在业务复杂的情况下，页面的渲染部分的代码，非常复杂。
   
2. 在json返回的数据比较大的情况下，渲染的十分缓慢，会出现页面卡顿的情况
3. seo非常不方便，由于搜索引擎的爬虫无法爬下js异步渲染的数据，导致这样的页面，SEO会存在一定的问题。
4. 资源消耗严重，在业务复杂的情况下，一个页面可能要发起多次http请求才能将页面渲染完毕。

为什么是半分离？
前端和后台同时开发时，就可能遇到前端已经开发好一个页面了，可是却等待后台api接口的情况。比如说A是负责前端，B是负责后台，A可能用了一周做好了基本的结构，并且需要API接口联调后，才能继续开发，而此时B却还没有实现好所需要的接口，这种情况
前端自己手上没有测试数据，无法模拟线上开发环境

分离

引入Node.js

1. 引入nodejs主要是为了分层开发，职责划分。
   nodejs作为前端服务器，由前端开发人员负责，前端开发人员不需要知道java后台的api接口是如何实现的，前端只需要关心前端的开发工作，并且管理好nodejs前端服务器，而后台开发人员也不需要考虑如何前端是如何部署的，他只需要做好自己擅长的部分，提供好API接口就可以

2. 前端可以使用node.js生成假数据，不需要等待后端的api完成就可以模拟线上开发环境

数据和视图绑定

过多的js代码操作dom会造成大量冗余，代码结构杂乱无章，不好维护，为了解决这个问题，前端三大框架(Vue React Angular)运营而生。

他们的核心思想是将数据(Model)和视图(View)进行绑定。

vue还可以使用组件技术组织网页中的各个模块，看起来更加有序，好维护

由此开始前端正式和后端说再见了

微服务

前端和后端划清关系之后，后端更加注重处理自己的业务逻辑
随着应用更加复杂，功能划分更细，需要将一个大的系统拆分成小系统，每个小系统都可以对外提供一种类型的服务，微服务逐渐兴起。

正如前端有vue全家桶 java后台有sring全家桶

看网课的一些笔记 📝

影响性能的几个方面 🔰

• 服务器硬件 CPU 内存 I/O子系统 网络
• 服务器操作系统
• 数据库存储引擎的选择
• 数据库参数配置 => 影响巨大
• 数据库结构设计和SQL语句 => 慢查询

数据库结构优化 🔧

目的:

• 减少数据冗余
• 尽量避免数据维护中出现更新, 插入, 删除异常
  • 插入异常: 表中某个实体随另一个实体存在
  • 更改表中某个实体的单独属性时, 需要对多行进行更新
  • 删除b表中的某一实体会导致其他实体的消失

逻辑设计

范式化:

• 可以尽量减少数据冗余 😊
• 更新操作比反范式化快 😊
• 表通常比反范式化小 😊
• 对于查询需要对多个表进行关联 😔
• 更难进行索引优化 😔

反范式化:

• 可以减少表的关联 😊
• 更好进行索引优化 😊
• 存在数据冗余和数据维护异常 😔
• 对数据的修改需要更多成本 😔

在范式化基础上适当反范式化

物理设计

选择合适的存储引擎:

为表中的字段选择合适的数据类型:
当一个列可以选择多种数据类型时, 应该优先考虑数字类型, 其次是日期或二进制类型, 最后是字符类型. 对于相同级别的数据类型, 应该优先选择占用空间小的数据类型.

• 财务相关数据应选择decimal
• varchar和char的宽度是以字符(而不是字节)为单位, 如UTF-8一个字符占用3个字节
• varchar不定长, 适用场景:
  1. 字符串列的最大长度比平均长度大很多
  2. 字符串列很少被更新
  3. 使用了多字节字符集(UTF-8)存储字符串
• char定长, 适用场景:
  1. 适合存储长度近似的值(md5, 身份证)
  2. 短字符串(性别)
  3. 经常更新的字符串列

日期类型:

• datatime: YYYY-MM-DD HH:MM:SS[.fraction]
  与时区无关, 占用8个字节
  范围: 1000-01-01 00:00:00 – 9999-12-31 23:59:59
• timestamp: YYYY-MM-DD HH:MM:SS[.fraction]
  时区有关, 时间戳, 占用4个字节 在行的数据修改时可以自动修改timestamp列的值
  范围: 1970-01-01 00:00:00 – 2038-01-19 23:59:59
• date: YYYY-MM-DD
  可以用date存储日期, 只要3个字节
  可以用日期时间函数进行日期间的计算
  范围: 1000-01-01 – 9999-12-31
• time: HH:MM:SS[.fraction]

不要用字符串类型存储日期时间

如何为InnoDB选择逐渐:

• 主键应该尽可能的小
• 主键应该是顺序增长的
• InnoDB的主键和业务主键可以不同

数据库索引优化 📌

为什么使用索引:

• 大大减少了存储引擎需要扫描的数据量
• 进行排序时避免使用临时表
• 可以把随机I/O变为顺序I/O

索引不是越多越好:

• 会增加写操作的成本
• 会增加查询优化器的选择时间

B-tree索引

特点:

• 以B+树结构存储数据
• 加快数据查询速度
• 适合进行范围查找

什么时候用到 😊

• 等值查询
  user_name=”bxy”
• 匹配最左前缀查询
  联合索引(user_name, id) 查询条件为user_name列时, 会使用该联合索引
• 匹配列前缀查询
  user_name like ‘bx%’
• 范围查找
  id > 10 and id < 100
• 精确匹配左前列并范围匹配另外一列
  精确匹配user_name 并范围查询id
• 只访问索引的查询
  只需访问索引, 无需访问数据行(无需回表操作) 即覆盖索引

使用限制 😔

• 如果不是按照索引最左列开始查找, 则无法使用索引
  联合索引(user_name, id) 查询条件为id列时, 无法使用该联合索引
• 使用索引时不能跳过索引中的列
  联合索引(user_name, id, role) 查询条件包含user_name和role 只有user_name会用到该联合索引
• not in 和 <> 操作无法使用索引
• 如果查询中有某个列的范围查询, 则其右边的所有列都无法使用索引
  联合索引(id, role, …) id使用范围查询, 则其右边的列都无法使用索引

Hash索引

特点:

• 基于hash表实现
• 只能用在等值查询中
• hash索引中的所有列, 存储引擎都会每一行计算一个hash码, hash索引中存储的是hash码

限制:

• hash索引必须进行二次查找
  索引中没有保存字段的值, 先通过hash索引找到对应的行, 再从行中读取字段
• 无法用于排序
• 不支持部分索引查找也不支持范围查找
• hash码的计算可能存在hash冲突, 不适合用用在选择性差的列上(如性别, 只有男和女)

索引优化策略

• 索引列上不能使用函数或表达式
  
• 注意控制前缀索引的长度和索引列的选择性
• 建立联合索引
  • 经常会被使用到的列优先
  • 选择性高的列优先
  • 宽度小的列优先
• 使用索引覆盖

利用索引优化锁:

• 索引可以减少锁定的行数
• 索引可以加快处理速度, 同时也加快锁的释放

删除重复和冗余索引:

• primary key(id), unique key(id), index(id)
• index(a), index(a, b)
• primary key(id), index(a, id)

SQL查询优化 🔎

获取有性能问题的SQL途径:

• slow_query_log 启动慢查询日志
  常用慢查询日志分析工具: mysqldumpslow pt-query-digest
• 通过information_schema中的processlist表来实时获取有性能问题的SQL

确定查询处理各个阶段消耗的时间:

• 使用profile
• 使用performance_schema

特定的SQL查询优化:

• 修改大表的表结构 使用pt-online-schema-change
• 如何优化not in和<>查询
  
• 使用汇总表优化查询
• 待汇总…

数据库分库分表 📦

分库分表可以分担主数据库的写负载, 主从复制可以分担主数据库的读负载

不到万不得已不用考虑数据库分片

待汇总…

MySQL主从复制 💾

复制解决了什么问题:

• 实现在不同服务器上的数据分布
• 实现数据读取的负载均衡
• 增强了数据的安全性
• 实现数据库高可用和故障切换
• 实现数据库在线升级

二进制日志

二进制日志binlog是MySQL服务层日志, 记录了所有对MySQL数据库的修改事件, 包括CRUD和对表结构的修改事件

二进制日志的格式:

• 基于段的格式 binlog_format=STATEMENT 记录的是SQL语句
  • 日志记录量相对较小, 节约磁盘及网络I/O 😊
    只对一条记录修改或插入, row格式所产生的日志量小于段产生的日志量
  • 必须要记录上下文信息, 保证语句在服务器上执行结果和在主服务器上相同 😔
    特定函数如UUID(), user() 这样非确定性函数还是无法复制
    可能造成MySQL复制的主备服务器数据不一致
• 基于行的日志格式 binlog_format=ROW (version > 5.7 default) 记录的是修改记录行的信息
  • 可以避免MySQL复制中出现的主从不一致问题 😊
    对每一行数据的修改比基于段的复制高效
  • 记录日志量较大 😔
    binlog_row_image=[FULL | MINIMAL | NOBLOB]
• 混合日志格式 binlog_format=MIXED
  • 根据SQL语句由系统决定在段or行的日志格式中选择
  • 数据量的大小由所执行的SQL语句决定

二进制日志格式对复制的影响

基于SQL语句的复制(SBR)

优点:

• 生成的日志量少, 节约网络传输I/O
• 不强制要求主从数据库的表定义完全相同
• 相比于基于行的复制方式更为灵活

缺点:

• 对于非确定性事件, 无法保证主从复制数据一致性
• 对于存储过程, 触发器, 自定义函数进行的修改也可能造成数据不一致
• 相比于基于行的复制方式在从库上执行需要更多的行锁

基于行的复制(RBR) 👍

优点:

• 可以应用于任何SQL的复制包括非确定性函数, 存储过程等
• 可以减少从库锁的使用

缺点:

• 要求主从数据库的表结构相同, 否则可能会中断复制
• 无法在从库上单独执行触发器

MySQL复制工作方式

1. 主服务器将变更写入二进制日志(需先开启binlog, 否则再开启要重启数据库服务器)
2. 从服务器读取主服务器的二进制日志变更并写入到relay_log中
   在从服务器上启动一个工作线程(I/O线程)与主库建立客户端连接, 在主库上启动二进制转储线程(binlogdump), I/O线程就通过binlogdump读取主库的binlog中的事件
   根据从什么位置开始读取binlog, 可以分为
   • 基于日志点的复制
   • 基于GTID的复制
3. 从服务器读取relay_log中的事件, 在从库上重放(由SQL线程完成)

MySQL复制性能优化

影响主从延迟的因素

• 主库写入二进制日志的时间 => 控制主库的事务大小, 分割大事务
• 二进制日志传输时间 => 使用MIXED日志格式或设置set binlog_row_image=minimal
• 默认情况只有一个SQL线程, 主库上b并发的修改在从库上变成了串行 => 使用多线程复制

1-8讲是基础篇，学完了基础就到实战了，接下来的提炼就看心情吧。

06 | 全局锁和表锁 ：给表加个字段怎么有这么多阻碍？

根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。

全局锁

全局锁就是对整个数据库实例加锁。MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。使用这个命令之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。

全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都select出来存成文本。

备份表不加锁的问题：

备份系统备份的得到的库不是一个逻辑时间点，这个视图是逻辑不一致的。

解决：

在可重复读隔离级别下开启一个事务：官方自带的逻辑备份工具是mysqldump。当mysqldump使用参数–single-transaction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的。

为什么有了mysqldump还需要FTWRL?

有些引擎（MyISAM）不支持事务，也就不支持可重复读隔离级别，所以，single-transaction方法只适用于所有的表使用事务引擎的库。如果有的表使用了不支持事务的引擎，那么备份就只能通过FTWRL方法。

为什么不使用set global readonly=true的方式?

readonly方式也可以让全库进入只读状态，但还是建议用FTWRL方式，主要有两个原因：

• 在有些系统中，readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大，不建议使用。

• 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开，那么MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高。

表级锁

MySQL里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。

表锁

表锁的语法是 lock tables … read/write。可以用unlock tables主动释放锁，也可以在客户端断开的时候自动释放。需要注意，lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。

对于InnoDB这种支持行锁的引擎，一般不使用lock tables命令来控制并发，毕竟锁住整个表的影响面还是太大。

元数据锁

MDL不需要显式使用，在访问一个表的时候会被自动加上。MDL的作用是，保证读写的正确性。

在MySQL 5.5版本中引入了MDL，当对一个表做增删改查操作的时候，加MDL读锁；当要对表做结构变更操作的时候，加MDL写锁。

• 读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。

• 读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

事务中的MDL锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放。

如何安全地给小表加字段？

首先要解决长事务，事务不提交，就会一直占着MDL锁。在MySQL的information_schema 库的 innodb_trx 表中，可以查到当前执行中的事务。如果要做DDL变更的表刚好有长事务在执行，要考虑先暂停DDL，或者kill掉这个长事务。

如果要变更的表是一个热点表，虽然数据量不大，但是上面的请求很频繁，这时候kill可能未必管用，因为新的请求马上就来了。比较理想的机制是，在alter table语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到MDL写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。之后开发人员或者DBA再通过重试命令重复这个过程。MariaDB已经合并了AliSQL的这个功能。

07 | 行锁功过：怎么减少行锁对性能的影响？

MySQL的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如MyISAM引擎就不支持行锁。不支持行锁会影响到业务并发度。

两阶段锁协议

在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

如果事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。

如下面这个例子：

实现一个电影票在线交易业务，顾客A要在影院B购买电影票。简化一点，这个业务需要涉及到以下操作：

1. 从顾客A账户余额中扣除电影票价；
2. 给影院B的账户余额增加这张电影票价；
3. 记录一条交易日志。

如果同时有另外一个顾客C要在影院B买票，那么这两个事务冲突的部分就是语句2了。因为它们要更新同一个影院账户的余额，需要修改同一行数据。

根据两阶段锁协议，不论怎样安排语句顺序，所有的操作需要的行锁都是在事务提交的时候才释放的。所以，如果把语句2安排在最后，比如按照3、1、2这样的顺序，那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待，提升了并发度。

死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。

当出现死锁以后，有两种策略：

• 直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置。

• 发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑。

正常情况下还是要采用第二种策略，即：主动死锁检测，而且innodb_deadlock_detect的默认值本身就是on。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。

死锁检测要耗费大量的CPU资源，怎么解决由这种热点行更新导致的性能问题呢？

• 如果能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。

• 从设计上优化，以影院账户为例，可以考虑放在多条记录上，比如10个记录，影院的账户总额等于这10个记录的值的总和。这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的1/10，可以减少锁等待个数，也就减少了死锁检测的CPU消耗。

08 | 事务到底是隔离的还是不隔离的？

开篇问题，事务B查到的k的值是3，而事务A查到的k的值是1，为什么？

需要注意事务的启动时机：

begin/start transaction 命令并不是一个事务的起点，在执行到它们之后的第一个操作InnoDB表的语句，事务才真正启动。如果想要马上启动一个事务，可以使用start transaction with consistent snapshot 这个命令。事务C没有显式地使用begin/commit，表示这个update语句本身就是一个事务，语句完成的时候会自动提交。

在MySQL里，有两个“视图”的概念：

• 一个是view。它是一个用查询语句定义的虚拟表，在调用的时候执行查询语句并生成结果。创建视图的语法是create view … ，而它的查询方法与表一样。

• 另一个是InnoDB在实现MVCC时用到的一致性读视图，即consistent read view，用于支持RC（Read Committed，读提交）和RR（Repeatable Read，可重复读）隔离级别的实现。它没有物理结构，作用是事务执行期间用来定义“我能看到什么数据”。

“快照”在MVCC里是怎么工作的？

InnoDB里面每个事务有一个唯一的事务ID，叫作transaction id。它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。

每行数据也都是有多个版本的。每次事务更新数据的时候，都会生成一个新的数据版本，并且把transaction id赋值给这个数据版本的事务ID，记为row trx_id。

在实现上， InnoDB为每个事务构造了一个数组，用来保存这个事务启动瞬间，当前正在“活跃”的所有事务ID。“活跃”指的就是，启动了但还没提交。

数组里面事务ID的最小值记为低水位，当前系统里面已经创建过的事务ID的最大值加1记为高水位。视图数组和高水位，就组成了当前事务的一致性视图（read-view）。

视图数组把所有的row trx_id 分成了几种不同的情况。

对于当前事务的启动瞬间来说，一个数据版本的row trx_id，有以下几种可能：

1. 如果落在绿色部分，表示这个版本是已提交的事务或者是当前事务自己生成的，这个数据是可见的；

2. 如果落在红色部分，表示这个版本是由将来启动的事务生成的，是肯定不可见的；

3. 如果落在黄色部分，那就包括两种情况

• 若 row trx_id在数组中，表示这个版本是由还没提交的事务生成的，不可见；
• 若 row trx_id不在数组中，表示这个版本是已经提交了的事务生成的，可见。

InnoDB利用了“所有数据都有多个版本”的这个特性，实现了“秒级创建快照”的能力。

回到开篇问题，利用上面的理论画图理解

事务A查询语句的读数据流程是这样的：

• 找到(1,3)的时候，判断出row trx_id=101，比高水位大，处于红色区域，不可见；
• 接着，找到上一个历史版本，一看row trx_id=102，比高水位大，处于红色区域，不可见；
• 再往前找，终于找到了（1,1)，它的row trx_id=90，比低水位小，处于绿色区域，可见。

翻译一下。一个数据版本，对于一个事务视图来说，除了自己的更新总是可见以外，有三种情况：

1. 版本未提交，不可见；

2. 版本已提交，但是是在视图创建后提交的，不可见；

3. 版本已提交，而且是在视图创建前提交的，可见。

利用这个规则判断事务A的查询结果，是这样的：

• (1,3)还没提交，属于情况1，不可见；
• (1,2)虽然提交了，但是是在视图数组创建之后提交的，属于情况2，不可见；
• (1,1)是在视图数组创建之前提交的，可见。

更新逻辑

更新数据都是先读后写的，而这个读，只能读当前的值，称为“当前读”（current read）。

事务的可重复读的能力是怎么实现的？

可重复读的核心就是一致性读（consistent read）；而事务更新数据的时候，只能用当前读。如果当前的记录的行锁被其他事务占用的话，就需要进入锁等待。

而读提交的逻辑和可重复读的逻辑类似，它们最主要的区别是：

• 在可重复读隔离级别下，只需要在事务开始的时候创建一致性视图，之后事务里的其他查询都共用这个一致性视图；

• 在读提交隔离级别下，每一个语句执行前都会重新算出一个新的视图。

事务A的查询语句的视图数组是在执行这个语句的时候创建的，时序上(1,2)、(1,3)的生成时间都在创建这个视图数组的时刻之前。但是，在这个时刻：

• (1,3)还没提交，属于情况1，不可见；
• (1,2)提交了，属于情况3，可见。

所以，这时候事务A查询语句返回的是k=2。显然地，事务B查询结果k=3。

小结一下

InnoDB的行数据有多个版本，每个数据版本有自己的row trx_id，每个事务或者语句有自己的一致性视图。普通查询语句是一致性读，一致性读会根据row trx_id和一致性视图确定数据版本的可见性。

• 对于可重复读，查询只承认在事务启动前就已经提交完成的数据；

• 对于读提交，查询只承认在语句启动前就已经提交完成的数据；

为啥会有这个系列呢，因为我这人比较功利，学到了东西怕忘了，忘了就等于没学，浪费时间，开这个系列是记录一些概念和知识点，方便以后查阅。文字基本是原文，我只是提炼一些关键的段落。

资料来源于极客时间林晓斌的《MySQL实战45讲》。

01 | 基础架构：一条SQL查询语句是如何执行的?

大体来说，MySQL可以分为Server层和存储引擎层两部分。

• Server层包括连接器、查询缓存、分析器、优化器、执行器等，涵盖MySQL的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

• 存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个存储引擎。现在最常用的存储引擎是InnoDB，它从MySQL 5.5.5版本开始成为了默认存储引擎。

连接器

第一步，会先连接到这个数据库上，这时候接待你的就是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理连接。

查询缓存

连接建立完成后，就可以执行select语句了。执行逻辑就会来到第二步：查询缓存。MySQL拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句，如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。MySQL 8.0版本直接将查询缓存的整块功能删掉了。

分析器

如果没有命中查询缓存，就要开始真正执行语句了。分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条SQL语句，MySQL需要识别出里面的字符串分别是什么，代表什么。

优化器

经过了分析器，MySQL就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。

执行器

进入了执行器阶段，开始执行语句。开始执行的时候，要先判断一下你对这个表T有没有执行查询的权限，如果没有，就会返回没有权限的错误，如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

数据库的慢查询日志中有一个rows_examined的字段，表示这个语句执行过程中扫描了多少行。这个值就是在执行器每次调用引擎获取数据行的时候累加的。
在有些场景下，执行器调用一次，在引擎内部则扫描了多行，因此引擎扫描行数跟rows_examined并不是完全相同的。

02 | 日志系统：一条SQL更新语句是如何执行的？

可以确定的说，查询语句的那一套流程，更新语句也是同样会走一遍。

执行语句前要先连接数据库，这是连接器的工作，接下来，分析器会通过词法和语法解析知道这是一条更新语句。优化器决定要使用ID这个索引。然后，执行器负责具体执行，找到这一行，然后更新。

与查询流程不一样的是，更新流程还涉及两个重要的日志模块：redo log（重做日志）和 binlog（归档日志）。

redo log

redo log是InnoDB引擎特有的日志。

如果每一次的更新操作都需要写进磁盘，然后磁盘也要找到对应的那条记录，然后再更新，整个过程IO成本、查找成本都很高，为了解决这个问题，MySQL里经常说到的WAL技术，WAL的全称是Write-Ahead Logging，它的关键点就是先写日志，再写磁盘。

具体来说，当有一条记录需要更新的时候，InnoDB引擎就会先把记录写到redo log里面，并更新内存，这个时候更新就算完成了。同时，InnoDB引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。

有了redo log，InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe。

binlog

binlog是Server层自己的日志。

为什么会有两份日志呢？

最开始MySQL里并没有InnoDB引擎。MySQL自带的引擎是MyISAM，但是MyISAM没有crash-safe的能力，binlog日志只能用于归档。而InnoDB是另一个公司以插件形式引入MySQL的，既然只依靠binlog是没有crash-safe能力的，所以InnoDB使用另外一套日志系统——也就是redo log来实现crash-safe能力。

这两种日志有以下三点不同

1. redo log是InnoDB引擎特有的；binlog是MySQL的Server层实现的，所有引擎都可以使用。

2. redo log是物理日志，记录的是“在某个数据页上做了什么修改”；binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这一行的c字段加1 ”。

3. redo log是循环写的，空间固定会用完；binlog是可以追加写入的。“追加写”是指binlog文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。

update语句的执行流程图，图中浅色框表示是在InnoDB内部执行的，深色框表示是在执行器中执行的。

两阶段提交

将redo log的写入拆成了两个步骤：prepare和commit，这就是”两阶段提交”。

如果不使用“两阶段提交”，那么数据库的状态就有可能和用它的日志恢复出来的库的状态不一致。

简单说，redo log和binlog都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

03 | 事务隔离：为什么你改了我还看不见？

提到事务，会想到ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）。

当数据库上有多个事务同时执行的时候，就可能出现脏读（dirty read）、不可重复读（non-repeatable read）、幻读（phantom read）的问题，为了解决这些问题，就有了“隔离级别”的概念。

• 读未提交是指，一个事务还没提交时，它做的变更就能被别的事务看到。
• 读提交是指，一个事务提交之后，它做的变更才会被其他事务看到。
• 可重复读是指，一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的。当然在可重复读隔离级别下，未提交变更对其他事务也是不可见的。
• 串行化，顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。

事务隔离的实现

在MySQL中，实际上每条记录在更新的时候都会同时记录一条回滚操作。记录上的最新值，通过回滚操作，都可以得到前一个状态的值。

假设一个值从1被按顺序改成了2、3、4，在回滚日志里面就会有类似下面的记录。

假设一个值当前是4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的read-view（视图）。假设在视图A、B、C里面，这一个记录的值分别是1、2、4，同一条记录在系统中可以存在多个版本，就是数据库的多版本并发控制（MVCC）。

回滚日志不能一直保留，什么时候删除呢？答案是，在不需要的时候才删除。也就是说，系统会判断，当没有事务再需要用到这些回滚日志时，回滚日志会被删除。

什么时候才不需要了呢？就是当系统里没有比这个回滚日志更早的read-view的时候。

为什么尽量不使用长事务

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。

事务的启动方式

MySQL的事务启动方式有以下几种：

1. 显式启动事务语句， begin 或 start transaction。配套的提交语句是commit，回滚语句是rollback。

2. set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个select语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行commit 或 rollback 语句，或者断开连接。

有些客户端连接框架会默认连接成功后先执行一个set autocommit=0的命令。这就导致接下来的查询都在事务中，如果是长连接，就导致了意外的长事务。

因此，建议总是使用set autocommit=1, 通过显式语句的方式来启动事务。

04 | 深入浅出索引（上）

索引的常见模型

哈希表

• 添加数据快
• 无序，做区间查询速度慢
• 适用于只有等值查询的场景

有序数组

• 添加数据麻烦，成本高
• 在等值查询和范围查询场景中的性能就都非常优秀
• 只适用于静态存储引擎

二叉搜索树

二叉树是搜索效率最高的，但是实际上大多数的数据库存储却并不使用二叉树。其原因是，索引不止存在内存中，还要写到磁盘上。

为了让一个查询尽量少地读磁盘，就必须让查询过程访问尽量少的数据块。那么，我们就不应该使用二叉树，而是要使用“N叉”树。这里，“N叉”树中的“N”取决于数据块的大小。

N叉树由于在读写上的性能优点，以及适配磁盘的访问模式，已经被广泛应用在数据库引擎中了。

InnoDB的索引模型

在InnoDB中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。

InnoDB使用了B+树索引模型，所以数据都是存储在B+树中的。

每一个索引在InnoDB里面对应一棵B+树。

假设，有一个主键列为ID的表，表中有字段k，并且在k上有索引。

根据叶子节点的内容，索引类型分为主键索引和非主键索引。

• 主键索引的叶子节点存的是整行数据。在InnoDB里，主键索引也被称为聚簇索引（clustered index）。

• 非主键索引的叶子节点内容是主键的值。在InnoDB里，非主键索引也被称为二级索引（secondary index）。

基于主键索引和普通索引的查询有什么区别？

• 如果语句是select * from T where ID=500，即主键查询方式，则只需要搜索ID这棵B+树；

• 如果语句是select * from T where k=5，即普通索引查询方式，则需要先搜索k索引树，得到ID的值为500，再到ID索引树搜索一次。这个过程称为回表。

也就是说，基于非主键索引的查询需要多扫描一棵索引树。因此，我们在应用中应该尽量使用主键查询。

索引维护

自增主键的插入数据模式，符合了递增插入的场景。每次插入一条新记录，都是追加操作，都不涉及到挪动其他记录，也不会触发叶子节点的分裂。

而有业务逻辑的字段做主键，则往往不容易保证有序插入，这样写数据成本相对较高。

假设表中确实有一个唯一字段，比如字符串类型的身份证号，那应该用身份证号做主键，还是用自增字段做主键呢？

由于每个非主键索引的叶子节点上都是主键的值。如果用身份证号做主键，那么每个二级索引的叶子节点占用约20个字节，而如果用整型做主键，则只要4个字节，如果是长整型（bigint）则是8个字节。

显然，主键长度越小，普通索引的叶子节点就越小，普通索引占用的空间也就越小。

所以，从性能和存储空间方面考量，自增主键往往是更合理的选择。

05 | 深入浅出索引（下）

索引覆盖

使用

1

select ID from T where k between 3 and 5

要比

1

select * from T where k between 3 and 5

好，因为前者只需要查ID的值，而ID的值已经在k索引树上了，因此可以直接提供查询结果，不需要回表。也就是说，在这个查询里面，索引k已经“覆盖了”我们的查询需求，我们称为覆盖索引。

由于覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段。

最左前缀原则

现有（name，age）这个联合索引，索引项是按照索引定义里面出现的字段顺序排序的。

需求是查到所有名字是“张三”的人时，可以快速定位到ID4，然后向后遍历得到所有需要的结果。

如果要查的是所有名字第一个字是“张”的人，SQL语句的条件是”where name like ‘张%’”。这时，也能够用上这个索引，查找到第一个符合条件的记录是ID3，然后向后遍历，直到不满足条件为止。

可以看到，不只是索引的全部定义，只要满足最左前缀，就可以利用索引来加速检索。这个最左前缀可以是联合索引的最左N个字段，也可以是字符串索引的最左M个字符。

在建立联合索引的时候，如何安排索引内的字段顺序？

第一原则是，如果通过调整顺序，可以少维护一个索引，那么这个顺序往往就是需要优先考虑采用的。

注意：查询条件里面只有b的语句，是无法使用(a,b)这个联合索引的，这时候你不得不维护另外一个索引，也就是说你需要同时维护(a,b)、(b) 这两个索引。

索引下推

现在有一个需求：检索出表中“名字第一个字是张，而且年龄是10岁的所有男孩”

1

select * from tuser where name like '张%' and age=10 and ismale=1;

MySQL 5.6之前，只能从ID3开始一个个回表。到主键索引上找出数据行，再对比字段值。

MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。

策略模式

描述：定义一个算法的系列，将其各个分装，并且使他们有交互性。策略模式使得算法在用户使用的时候能独立的改变。

什么时候用策略模式？
策略模式是用来封装算法的，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了算法类和使用算法类之间的耦合。在实践中，我们发现可以用它封装几乎任何类型的规则，只要在分析过程中听到需要在不同时机应用不同的业务规则，就可以用策略模式处理这种变化的可能性。

策略模式的3个角色

• Context（环境类）：环境类是使用算法的角色，它在解决某个问题（即实现某个方法）时可以采用多种策略。在环境类中维持一个对抽象策略类的引用实例，用于定义所采用的策略。

• Strategy（抽象策略类）：它为所支持的算法声明了抽象方法，是所有策略类的父类，它可以是抽象类或具体类，也可以是接口。环境类通过抽象策略类中声明的方法在运行时调用具体策略类中实现的算法。

• ConcreteStrategy（具体策略类）：它实现了在抽象策略类中声明的算法，在运行时，具体策略类将覆盖在环境类中定义的抽象策略类对象，使用一种具体的算法实现某个业务处理。

策略模式实现起来也十分简单，随便写个代码示范就好

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

//Strategy
abstract class FastFood {
    abstract void getFood();
}

//ConcreteStrategy
class KFC extends FastFood {
    @Override
    void getFood() {
        System.out.println("点开封菜！");
    }
}

class McDonalds extends FastFood {
    @Override
    void getFood() {
        System.out.println("点金拱门！");
    }
}

//Context
class TakeawayPlatform {
    FastFood fastFood;

    public TakeawayPlatform(FastFood fastFood) {
        this.fastFood = fastFood;
    }

    public void getFood() {
        fastFood.getFood();
    }
}

//策略模式结合简单工厂
class TakeawayFactory {
    FastFood fastFood = null;

    private final String KFC = "KFC";
    private final String McDonalds = "McDonalds";

    public TakeawayFactory(String type) {
        switch (type) {
            case KFC:
                fastFood = new KFC();
                break;
            case McDonalds:
                fastFood = new McDonalds();
                break;
        }
    }

    public void getFood() {
        fastFood.getFood();
    }
}

主程序

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

public class Strategy {
    public static void main(String[] args) {
        TakeawayPlatform takeawayKFC = new TakeawayPlatform(new KFC());
        takeawayKFC.getFood();

        TakeawayPlatform takeawayMCD = new TakeawayPlatform(new McDonalds());
        takeawayMCD.getFood();

        TakeawayFactory takeawayFactory = new TakeawayFactory("KFC");
        takeawayFactory.getFood();
    }
}

在基本策略模式中，选择ConcreteStrategy的职责由客户端承担，并转给Context对象。这并没有解除客户端需要选择判断的压力，而策略模式和简单工厂模式结合后，选择的职责也可以由Context承担，这最大化减轻了客户端的职责。

模版方法模式

描述：模板方法模式准备一个抽象类，将部分逻辑以具体方法及具体构造子类的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先构建一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

什么时候用模版方法模式？
模版方法模式提供了很好的代码复用平台，当遇到一些列步骤构成的过程需要执行，这些过程从高层次上看是相似的，只是有些具体步骤实现可能不同，这时可以考虑使用模版方法模式。

模版方法模式的2个角色

• AbstractClass（抽象类）：在抽象类中定义了一系列基本操作(PrimitiveOperations)，这些基本操作可以是具体的，也可以是抽象的，每一个基本操作对应算法的一个步骤，在其子类中可以重定义或实现这些步骤。同时，在抽象类中实现了一个模板方法(Template Method)，用于定义一个算法的框架，模板方法不仅可以调用在抽象类中实现的基本方法，也可以调用在抽象类的子类中实现的基本方法，还可以调用其他对象中的方法。

• ConcreteClass（具体子类）：它是抽象类的子类，用于实现在父类中声明的抽象基本操作以完成子类特定算法的步骤，也可以覆盖在父类中已经实现的具体基本操作。

一个模板方法是定义在抽象类中的、把基本操作方法组合在一起形成一个总算法或一个总行为的方法。这个模板方法定义在抽象类中，并由子类不加以修改地完全继承下来。模板方法是一个具体方法，它给出了一个顶层逻辑框架，而逻辑的组成步骤在抽象类中可以是具体方法，也可以是抽象方法。

基本方法是实现算法各个步骤的方法，是模板方法的组成部分。基本方法又可以分为三种：抽象方法(Abstract Method)、具体方法(Concrete Method)和钩子方法(Hook Method)。

• 抽象方法：一个抽象方法由抽象类声明、由其具体子类实现。
• 具体方法：一个具体方法由一个抽象类或具体类声明并实现，其子类可以进行覆盖也可以直接继承。
• 钩子方法：可以与一些具体步骤 “挂钩” ，以实现在不同条件下执行模板方法中的不同步骤

做奶茶的基本工序大致是相同的，加奶加茶，顾客选择加料加冰甜度等等，最后塑封。用代码演示如下

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

//AbstractClass
abstract class MilkTea {
    //模版方法，注意要加final让子类不能改写
    protected final void makeMilkTea() {
        addMilk();
        addTea();
        if (needIce()) {
            addIce();
        }
        addStuff();
        packUp();
    }

    final void addMilk() {
        System.out.println("添加牛奶");
    }

    final void addTea() {
        System.out.println("添加茶汁");
    }

    final void addIce() {
        System.out.println("添加冰块");
    }

    final void packUp() {
        System.out.println("塑封，完成！");
    }

    protected boolean needIce() {
        return false;
    }

    abstract void addStuff();
}

//ConcreteClass
class PearlMilkTea extends MilkTea {
    @Override
    void addStuff() {
        System.out.println("加珍珠");
    }
}

class RedBeanMilkTeaWithIce extends MilkTea {
    @Override
    protected boolean needIce() {
        return true;
    }

    @Override
    void addStuff() {
        System.out.println("加红豆");
    }
}

主程序

1
2
3
4
5
6
7
8
9
10
11

public class TemplateMethod {
    public static void main(String[] args) {
        System.out.println("-----开始制作珍珠奶茶-----");
        MilkTea pearl = new PearlMilkTea();
        pearl.makeMilkTea();

        System.out.println("-----开始制作红豆奶茶加冰-----");
        MilkTea redBean = new RedBeanMilkTeaWithIce();
        redBean.makeMilkTea();
    }
}

当不变的和可变的行为在方法的子类实现混合在一起时，不变的行为就会在子类中重复出现。通过模版方法模式把不变的行为搬到单一的地方，这样帮助子类摆脱重复不变行为的纠缠

参考资料：

• https://blog.csdn.net/wwwdc1012/article/details/83152856
• https://blog.csdn.net/wwwdc1012/article/details/83005717
• 《大话设计模式》

状态模式

描述：让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能获取的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

什么时候用状态模式？
当一个对象的行为取决于它的状态，且它必须在运行时刻根据状态改变它的行为时，就考虑用状态模式。状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。

状态模式的3个角色

• Context（环境角色）: 它定义了客户程序需要的接口并维护一个具体状态角色的实例，将与状态相关的操作委托给当前的具体状态对象来处理。

• State（抽象状态）: 定义一个接口以封装使用上下文环境的的一个特定状态相关的行为。

• ConcreteState（具体状态）:实现抽象状态定义的接口。

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

//State
abstract class Period {
    abstract void eat(MealTime mealTime);
}

//ConcreteState
class Morning extends Period {
    @Override
    void eat(MealTime mealTime) {
        if (mealTime.hour > 6 && mealTime.hour <= 9) {
            System.out.println("现在是早上，可以吃包子喝豆浆");
        } else {
            mealTime.setCurrent(new Noon());
            mealTime.eat();
        }
    }
}

class Noon extends Period {
    @Override
    void eat(MealTime mealTime) {
        if (mealTime.hour > 9 && mealTime.hour <= 13) {
            System.out.println("快到中午了，可以吃大碗宽面");
        } else {
            mealTime.setCurrent(new Afternoon());
            mealTime.eat();
        }
    }
}

class Afternoon extends Period {
    @Override
    void eat(MealTime mealTime) {
        if (mealTime.hour > 13 && mealTime.hour <= 17) {
            System.out.println("现在是下午，给阿姨倒杯卡布奇诺");
        } else {
            mealTime.setCurrent(new Evening());
            mealTime.eat();
        }
    }
}

class Evening extends Period {
    @Override
    void eat(MealTime mealTime) {
        if (mealTime.hour > 17 && mealTime.hour <= 22) {
            System.out.println("现在是晚上，可以吃葱油拌面");
        } else {
            System.out.println("想吃夜宵？不怕长膘？");
        }
    }
}

//Context
class MealTime {
    private Period current;
    protected double hour;

    public MealTime() {
        current = new Morning();
    }

    public void setCurrent(Period current) {
        this.current = current;
    }

    public double getHour() {
        return hour;
    }

    public void setHour(double hour) {
        this.hour = hour;
    }

    public void eat() {
        current.eat(this);
    }
}

主程序

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

public class State {
    public static void main(String[] args) {
        MealTime mealTime = new MealTime();
        mealTime.setHour(7);
        mealTime.eat();
        mealTime.setHour(10);
        mealTime.eat();
        mealTime.setHour(15);
        mealTime.eat();
        mealTime.setHour(18);
        mealTime.eat();
        mealTime.setHour(23);
        mealTime.eat();
    }
}

可以看到，客户端只更改了状态的某一参数，就有不同的行为。调用具体方法eat()的时候，是看不到有选择的过程的，避免了大量的if else判断。

状态模式的好处
将与特定状态相关的行为局部化，并且将不同状态的行为分割开。可以消除庞大的分支语句，通过定义新的子类可以很容易地增加新的状态和转换。

备忘录模式

描述：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

什么时候用备忘录模式？
备忘录模式适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性的小部分时。

tips: 在某个系统使用命令模式时，需要实现命令的撤销功能，可以使用备忘录模式来存储可撤销操作的状态

备忘录模式的3个角色

• Originator（原发器）：它是一个普通类，可以创建一个备忘录，并存储它的当前内部状态，也可以使用备忘录来恢复其内部状态，一般将需要保存内部状态的类设计为原发器。

• Memento（备忘录)：存储原发器的内部状态，根据原发器来决定保存哪些内部状态。备忘录的设计一般可以参考原发器的设计，根据实际需要确定备忘录类中的属性。需要注意的是，除了原发器本身与负责人类之外，备忘录对象不能直接供其他类使用，原发器的设计在不同的编程语言中实现机制会有所不同。

• Caretaker（负责人）：负责人又称为管理者，它负责保存备忘录，但是不能对备忘录的内容进行操作或检查。在负责人类中可以存储一个或多个备忘录对象，它只负责存储对象，而不能修改对象，也无须知道对象的实现细节。

备忘录模式的核心是备忘录类以及用于管理备忘录的负责人类的设计。

用备忘录模式模拟下棋时的悔棋操作

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

//Originator
class Chessman {
    private String label;
    private int x;
    private int y;

    public Chessman(String label, int x, int y) {
        this.label = label;
        this.x = x;
        this.y = y;
    }

    public void setPosition(int x, int y) {
        this.x = x;
        this.y = y;
    }

    //保存状态
    public ChessmanMemento save() {
        return new ChessmanMemento(label, x, y);
    }

    //恢复状态
    public void restore(ChessmanMemento memento) {
        this.label = memento.getLabel();
        this.x = memento.getX();
        this.y = memento.getY();
    }

    public void show() {
        System.out.println(String.format("棋子<%s>：当前位置为：<%d, %d>", label, x, y));
    }
}

//Memento
class ChessmanMemento {
    private String label;
    private int x;
    private int y;

    public ChessmanMemento(String label, int x, int y) {
        this.label = label;
        this.x = x;
        this.y = y;
    }

    public String getLabel() {
        return label;
    }

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }
}

//Caretaker
class MementoCaretaker {
    private ChessmanMemento memento;

    public ChessmanMemento getMemento() {
        return memento;
    }

    public void setMemento(ChessmanMemento memento) {
        this.memento = memento;
    }
}

主程序

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

public class Memento {
    public static void main(String[] args) {
        Chessman chessman = new Chessman("黑子", 1, 1);
        chessman.show();

        MementoCaretaker caretaker = new MementoCaretaker();
        caretaker.setMemento(chessman.save());

        chessman.setPosition(2, 3);
        chessman.show();

        chessman.restore(caretaker.getMemento());
        chessman.show();
    }
}

观察者模式

描述：在对象间定义一个一对多的联系性，由此当一个对象改变了状态，所有其他相关的对象会被通知并且自动刷新。

观察者模式的动机
将一个系统分割成一系列相互协作的类有很不好的副作用，即需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护，扩展和重用都带来不便。而观察者模式的关键对象是Subject和Observer，一个Subject可以有任意数目依赖它的Observer，一旦Subject的状态发生变化，所有的Observer都可以得到通知。Subject发出通知时不需要知道它的观察者是谁，任何一个具体观察者也不需要知道其他观察者存在。

什么时候用观察者模式？
当一个对象的改变需要同时改变其他对象，且不知道具体有多少对象有待改变时；一个抽象模型有两个方面，其中一方面依赖于另外一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立改变和复用。

观察者模式的4个角色

• Subject（目标）：目标又称为主题，它是指被观察的对象。在目标中定义了一个观察者集合，一个观察目标可以接受任意数量的观察者来观察，它提供一系列方法来增加和删除观察者对象，同时它定义了通知方法notify()。目标类可以是接口，也可以是抽象类或具体类。

• ConcreteSubject（具体目标）：具体目标是目标类的子类，通常它包含有经常发生改变的数据，当它的状态发生改变时，向它的各个观察者发出通知；同时它还实现了在目标类中定义的抽象业务逻辑方法（如果有的话）。如果无须扩展目标类，则具体目标类可以省略。

• Observer（观察者）：观察者将对观察目标的改变做出反应，观察者一般定义为接口，该接口声明了更新数据的方法update()，因此又称为抽象观察者。

• ConcreteObserver（具体观察者）：在具体观察者中维护一个指向具体目标对象的引用，它存储具体观察者的有关状态，这些状态需要和具体目标的状态保持一致；它实现了在抽象观察者Observer中定义的update()方法。通常在实现时，可以调用具体目标类的attach()方法将自己添加到目标类的集合中或通过detach()方法将自己从目标类的集合中删除。

举个微信公众号推送的例子，非常契合

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

//Observer
interface Subscriber {
    void receive(String publisher, String articleName);
}

//ConcreteObserver
class WeChatClient implements Subscriber {
    private String username;

    public WeChatClient(String username) {
        this.username = username;
    }

    @Override
    public void receive(String publisher, String articleName) {
        System.out.println(String.format("用户<%s> 接收到 <%s>微信公众号 的推送，文章标题为 <%s>", username, publisher, articleName));
    }
}

//Subject
class Publisher {
    private List<Subscriber> subscribers;
    private boolean pubStatus = false;

    public Publisher() {
        subscribers = new ArrayList<>();
    }

    public void subscribe(Subscriber subscriber) {
        this.subscribers.add(subscriber);
    }

    public void unsubscribe(Subscriber subscriber) {
        if (this.subscribers.contains(subscriber)) {
            this.subscribers.remove(subscriber);
        }
    }

    public void notifySubscribers(String publisher, String articleName) {
        if (!this.pubStatus) {
            return;
        }
        for (Subscriber subscriber : this.subscribers) {
            subscriber.receive(publisher, articleName);
        }
        this.clearPubStatus();
    }

    protected void setPubStatus() {
        this.pubStatus = true;
    }

    protected void clearPubStatus() {
        this.pubStatus = false;
    }
}

//ConcreteSubject
class WeChatAccounts extends Publisher {
    private String name;

    public WeChatAccounts(String name) {
        this.name = name;
    }

    public void publishArticles(String articleName, String content) {
        System.out.println(String.format("\n<%s>微信公众号 发布了一篇推送，文章名称为 <%s>，内容为 <%s> ", this.name, articleName, content));
        setPubStatus();
        notifySubscribers(this.name, articleName);
    }
}

主程序

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

public class Observer {
    public static void main(String[] args) {
        WeChatAccounts accounts = new WeChatAccounts("X博士");

        WeChatClient user1 = new WeChatClient("ayahiro");
        WeChatClient user2 = new WeChatClient("bxy0516");
        WeChatClient user3 = new WeChatClient("tom");

        accounts.subscribe(user1);
        accounts.subscribe(user2);
        accounts.subscribe(user3);

        accounts.publishArticles("article1", "something1");

        accounts.unsubscribe(user1);
        accounts.publishArticles("article2", "something2");
    }
}

总的来说，观察者模式所做的工作是在解除耦合，让耦合的双方都依赖于抽象，而不是依赖于具体，是依赖倒转原则的最佳体现。

参考资料：

• https://blog.csdn.net/wwwdc1012/article/details/83353580
• https://blog.csdn.net/wwwdc1012/article/details/83317973
• https://xuwujing.blog.csdn.net/article/details/83589031
• 《大话设计模式》

为什么需要日志

当应用程序部署到服务器上运行时，用户在使用过程中可能会出现各种错误。这时应用程序将错误信息生成日志，就方便了开发人员快速定位错误和根源，从而进行有针对的维护。所以，在大型应用程序中，日志记录是必不可少的。

选择日志框架

目前市面上可供选择的日志框架非常多，如JCL、SLF4J、Jboss-logging、jUL、log4j、log4j2、logback等，首先要分清楚 [日志抽象层] 和 [日志实现]。 这两者的关系可以参考设计模式中的“门面模式”。 我们在开发中调用日志记录方法时，不应直接调用日志实现类的方法，而是调用日志抽象层的方法。这样方便解耦，以后想更换别的日志实现时，可以直接改动配置文件的信息，而不用修改一行代码。 那么如何选择日志框架呢？

• 日志抽象层：JCL（Jakarta Commons Logging), SLF4j（Simple Logging Facade for Java）, jboss-logging
• 日志实现：Log4j, JUL（java.util.logging）, Log4j2, Logback

关于如何选择网络上有很多文章分析，在此不赘述。结论就是SLF4J更受开发者青睐，事实上《阿里java开发手册》上也规定：应用中不可直接使用日志系统（Log4j、Logback）中的API，而应依赖使用日志框架
SLF4J中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。
至于选择日志实现，log4j是很常用的，但其作者又写了log4j的升级版logback，相比log4j有更好的性能。有诸多理由让我们选择logback，使用好logback关键的一点就是配置好logback.xml文件，可参阅logback使用和配置详解

maven引入

1
2
3
4
5
6
7
8

<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
</dependency>

SpringBoot已默认使用slf4j和logback 无需引入对应依赖。

如何插入日志记录

使用SpringAOP，目的是让开发者专注于业务逻辑而无需关心在哪里插入日志，并且可以降低日志记录操作对业务代码的侵入性。
这里我们使用 AspectJ 的几个注解来写一个切面类TestAspect.java

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

import com.example.demo.annotation.RequestColor;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;

@Aspect
@Component("testAspect")
public class TestAspect {
    private static final Logger logger = LoggerFactory.getLogger(TestAspect.class); 
    //controller包切点
    @Pointcut("execution(* com.example.demo.controller.*.*(..))")
    public void controllerPointCut() {
    }

    //TestController切点
    @Pointcut("execution(* com.example.demo.controller.TestController.*(..))")
    public void testControllerPointCut() {
    }

    //具体方法 ayahiro 切点
    @Pointcut("execution(* com.example.demo.controller.TestController.ayahiro()))")
    public void ayahiroPointCut() {
    }

    @Before(value = "testControllerPointCut()")
    public void doBefore(JoinPoint joinPoint){
        System.out.println("form: TestAspect---->>");
        String className=joinPoint.getSignature().getDeclaringTypeName();
        String methodName=joinPoint.getSignature().getName();
        System.out.println("doBefore拦截了"+className+"."+methodName);
    }

    @After(value = "@annotation(requestColor)")
    public void doAfter(JoinPoint joinPoint, final RequestColor requestColor){
        System.out.println("form: TestAspect---->>");
        String className=joinPoint.getSignature().getDeclaringTypeName();
        String methodName=joinPoint.getSignature().getName();
        System.out.println("doAfter拦截了"+className+"."+methodName);
        System.out.println("requestType: "+ requestColor.type());
    }

    @Around(value = "ayahiroPointCut()")
    public Object doAround(ProceedingJoinPoint joinPoint) throws Throwable{
        Object re=joinPoint.proceed();  //执行了ayahiro方法  返回了String
        System.out.println(re);
        System.out.println("form: TestAspect---->>");
        String className=joinPoint.getSignature().getDeclaringTypeName();
        String methodName=joinPoint.getSignature().getName();
        System.out.println("doAround拦截了"+className+"."+methodName);
        return re;
    }

    @AfterReturning(value = "testControllerPointCut()")
    public void doAfterReturning(JoinPoint joinPoint){
        System.out.println("form: TestAspect---->>");
        String className=joinPoint.getSignature().getDeclaringTypeName();
        String methodName=joinPoint.getSignature().getName();
        System.out.println("doAfterReturning拦截了"+className+"."+methodName);
    }

    @AfterThrowing(value = "testControllerPointCut()")
    public void doAfterThrowing(JoinPoint joinPoint){
        System.out.println("form: TestAspect---->>");
        String className=joinPoint.getSignature().getDeclaringTypeName();
        String methodName=joinPoint.getSignature().getName();
        System.out.println("doAfterThrowing拦截了"+className+"."+methodName);
    }
}

以及Controller，有两个返回字符串的测试方法

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

import com.example.demo.annotation.RequestColor;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class TestController {

    @RequestColor(type = RequestColor.Type.YELLOW)
    @RequestMapping(path = {"/ayahiro"},method = {RequestMethod.GET})
    public String ayahiro() throws Exception{
        //int num=2/0;
        return "this ayahiro";
    }

    @RequestMapping(path = {"/moonKa"},method = {RequestMethod.GET})
    public String moonKa(){
        return "this moonKa";
    }
}

介绍几个常用的注解

• @Aspect 表明这个类是“切面类”，切面类就是用来定义切点和切点处要增强功能的方法
• @Pointcut 这个注解包含两部分，PointCut表达式和PointCut签名。表达式是用来确定切入点的位置的，说白了就是通过一些规则来确定，哪些方法是要增强的，也就是要拦截哪些方法。注解括号里的部分就是描述切点的位置，有很多种方法来确定，代码中使用的execution表达式是其中的一种，其语法和其他描述方法可自行百度。 签名就是被注解的方法名，签名没有实际用处，只是用来标记一个Pointcut，可以理解成这个切入点的一个记号。
• @Before 顾名思义，即在切入点处方法执行前，执行此方法。同下面的@After，@Around，@AfterReturning， @AfterThrowing注解类似，都是规定了在何时(相对于待增强方法)执行被注解的方法。只不过注解属性有所区别
• JoinPoint 代表着织入增强处理的连接点。注意一点：除了注解@Around的方法外，其他都可以加这个JoinPoint作参数，@Around注解的方法的参数一定要是ProceedingJoinPoint。 JoinPoint包含了几个很有用的参数：
  • Object[] getArgs：返回目标方法的参数
  • Signature getSignature：返回目标方法的签名
  • Object getTarget：返回被织入增强处理的目标对象
  • Object getThis：返回AOP框架为目标对象生成的代理对象

运行效果

理解了几个注解的作用后，通过运行结果，来看看测试方法都被哪些增强方法拦截了
启动后，在浏览器输入http://localhost:8080/ayahiro

可以看到，ayahiro()被所有增强方法拦截了。testControllerPointCut()和ayahiroPointCut()拦截不难理解，都前者是划定了一个范围，后者是直接具体定位到该方法。其中@After(value = “@annotation(requestColor)”) 的拦截方式比较特别，是通过自定义注解拦截的，因为ayahiro()被@RequestColor修饰，而@After拦截所有被@RequestColor修饰的方法。
输入http://localhost:8080/moonKa

可以看到@After就没有拦截moonKa方法，因为该方法没有被@RequestColor修饰。

使用日志

理解了AOP的思想之后，再结合slf4j记录日志就显得非常简单，调用日志方法只需要声明一个 private static final Logger logger = LoggerFactory.getLogger(当前类.class); 再用loger去调用具体的方法：.info() .warn() .debug() .error()即可~

参考资料：

• https://www.cnblogs.com/wangshen31/p/9379197.html
• https://blog.csdn.net/caychen/article/details/80112915

访问者模式

描述：封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。

访问者模式的目的是要把处理从数据结构分离出来，有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式是合适的，因为它使得算法操作的增加变得容易。其缺点是增加新的数据结构变得困难。访问者模式比较复杂，当真正需要它的时候才考虑使用它。

访问者模式的5和角色

• Visitor（抽象访问者）角色：声明了一个或者多个方法操作，形成所有的具体访问者角色必须实现的接口。

• ConcreteVisitor（具体访问者）角色：实现抽象访问者所声明的接口，也就是抽象访问者所声明的各个访问操作。

• Element（抽象元素）：声明一个接受操作，接受一个访问者对象作为一个参数。

• ConcreteElement（具体元素）：实现了抽象节点所规定的接受操作。

• ObjectStructure（结构对象）：有如下的责任，可以遍历结构中的所有元素。

在本例中，把厕所当做抽象元素，具体元素有男厕所和女厕所，由此可见数据结构时稳定的，因为生理性别只有男女之分。进了厕所可以解大便解小便，洗手，抽烟，想干啥干啥。因此操作是多变的，这些操作都相当于是“放松”，把“放松”抽象成Visitor, 用代码模拟如下

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

//Visitor
abstract class Rest {
    public abstract void getManRest(ManRoom manRoom);

    public abstract void getWomanRest(WomanRoom womanRoom);
}

//ConcreteVisitor
class Stool extends Rest {
    @Override
    public void getManRest(ManRoom manRoom) {
        System.out.println(manRoom.getClass().getSimpleName() + "上大便");
    }

    @Override
    public void getWomanRest(WomanRoom womanRoom) {
        System.out.println(womanRoom.getClass().getSimpleName() + "上大便");
    }
}

class Pee extends Rest {
    @Override
    public void getManRest(ManRoom manRoom) {
        System.out.println(manRoom.getClass().getSimpleName() + "上小便");
    }

    @Override
    public void getWomanRest(WomanRoom womanRoom) {
        System.out.println(womanRoom.getClass().getSimpleName() + "上小便");
    }
}

//Element
abstract class Toilet {
    public abstract void accept(Rest rest);
}

//ConcreteElementA
class ManRoom extends Toilet {
    @Override
    public void accept(Rest rest) {
        rest.getManRest(this);
    }
}

//ConcreteElementB
class WomanRoom extends Toilet {
    @Override
    public void accept(Rest rest) {
        rest.getWomanRest(this);
    }
}

//ObjectStructure
class ToiletManager {
    private List<Toilet> elements = new ArrayList<>();

    public void attach(Toilet toilet) {
        elements.add(toilet);
    }

    public void detach(Toilet toilet) {
        elements.remove(toilet);
    }

    public void display(Rest rest) {
        for (Toilet toilet : elements) {
            toilet.accept(rest);
        }
    }
}

主程序

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

public class Visitor {
    public static void main(String[] args) {
        ToiletManager toiletManager = new ToiletManager();
        toiletManager.attach(new ManRoom());
        toiletManager.attach(new WomanRoom());

        Stool stool = new Stool();
        toiletManager.display(stool);

        Pee pee = new Pee();
        toiletManager.display(pee);
    }
}

中介者模式

描述：包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用，从而使它们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用，保证这些作用可以彼此独立的变化。

在开发中会遇到这样的场景：尽管将系统分割成许多对象通常可增加其可复用性，但是对象间相互连接的激增又会降低其可复用性了，大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分困难了，这就是中介者模式解决问题的背景。

中介者模式的4个角色

• Mediator（抽象中介者）：它定义一个接口，该接口用于与各同事对象之间进行通信。

• ConcreteMediator（具体中介者）：它是抽象中介者的子类，通过协调各个同事对象来实现协作行为，它维持了对各个同事对象的引用。

• Colleague（抽象同事类）：它定义各个同事类公有的方法，并声明了一些抽象方法来供子类实现，同时它维持了一个对抽象中介者类的引用，其子类可以通过该引用来与中介者通信。

• ConcreteColleague（具体同事类）：它是抽象同事类的子类；每一个同事对象在需要和其他同事对象通信时，先与中介者通信，通过中介者来间接完成与其他同事类的通信；在具体同事类中实现了在抽象同事类中声明的抽象方法。

中介者模式的核心在于中介者类的引入，在中介者模式中，中介者类承担了两方面的职责：

• 中转作用（结构性）：通过中介者提供的中转作用，各个同事对象就不再需要显式引用其他同事，当需要和其他同事进行通信时，可通过中介者来实现间接调用。该中转作用属于中介者在结构上的支持。

• 协调作用（行为性）：中介者可以更进一步的对同事之间的关系进行封装，同事可以一致的和中介者进行交互，而不需要指明中介者需要具体怎么做，中介者根据封装在自身内部的协调逻辑，对同事的请求进行进一步处理，将同事成员之间的关系行为进行分离和封装。

在本例中，买家和买家交易时使用移动支付，以前是使用纸币进行面对面交易。现在可以通过支付宝、微信转账交易，这些移动支付平台就相当于中介者。而支付宝、微信就是具体中介者了。

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

//Mediator
abstract class MobilePayment {
    public abstract void transfer(Account account, double amount);
}

//Colleague
abstract class Account {
    protected MobilePayment mobilePayment;

    public Account(MobilePayment mobilePayment) {
        this.mobilePayment = mobilePayment;
    }
}

//ConcreteColleague
class Seller extends Account {
    public Seller(MobilePayment mobilePayment) {
        super(mobilePayment);
    }

    public void transfer(double amount) {
        mobilePayment.transfer(this, amount);
    }

    public void notify(double amount) {
        System.out.println("卖家收到 " + amount + " 元");
    }
}

class Buyer extends Account {
    public Buyer(MobilePayment mobilePayment) {
        super(mobilePayment);
    }

    public void transfer(double amount) {
        mobilePayment.transfer(this, amount);
    }

    public void notify(double amount) {
        System.out.println("买家收到 " + amount + " 元");
    }
}

//ConcreteMediator
class Alipay extends MobilePayment {
    private Buyer buyer;
    private Seller seller;

    public void setBuyer(Buyer buyer) {
        this.buyer = buyer;
    }

    public void setSeller(Seller seller) {
        this.seller = seller;
    }

    @Override
    public void transfer(Account account, double amount) {
        if (account instanceof Buyer) {
            seller.notify(amount);
        } else {
            buyer.notify(amount);
        }
    }
}

主程序

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

public class Mediator {
    public static void main(String[] args) {
        Alipay alipay = new Alipay();

        Buyer buyer = new Buyer(alipay);
        Seller seller = new Seller(alipay);

        alipay.setBuyer(buyer);
        alipay.setSeller(seller);

        buyer.transfer(999);
    }
}

中介者模式很容易在系统中应用，也很容易误用。当系统中出现了“多对多”交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理。

优点：Mediator的出现减少了各个Colleague的耦合，使得可以独立改变和复用各个Colleague,由于把对象如何协作进行了抽象，将中介者作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身转移到它们之间的交互上来，也就是以更宏观的角度去看待系统。

缺点：由于ConcreteMediator控制了集中化，于是就把交互复杂性变为中介者复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。

参考资料：

• https://blog.csdn.net/wwwdc1012/article/details/83389158
• https://xuwujing.blog.csdn.net/article/details/83588888
• 《大话设计模式》

泛型类

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

public class Generic<T> {
    //key这个成员变量的类型为T,T的类型由外部指定
    private T key;

    public Generic(T key) { //构造方法形参key的类型也为T，T的类型由外部指定
        this.key = key;
    }

    public T getKey() { //方法getKey的返回值类型为T，T的类型由外部指定
        return key;
    }
}

< >里可以有多个参数

泛型接口

定义一个泛型接口

1
2
3

public interface Generator<T> {
    public T next();
}

传入泛型实参时：
定义一个生产器实现这个接口，虽然我们只创建了一个泛型接口Generator
但是我们可以为T传入无数种实参，形成无数种类型的Generator接口
在实现类实现泛型接口时，如已将泛型类型传入实参类型，则所有使用泛型的地方都要替换成传入的实参类型

即：Generator，public T next();中的的T都要替换成传入的String类型

1
2
3
4
5
6
7
8
9
10

public class FruitGenerator implements Generator<String> {

    private String[] fruits = new String[]{"Apple", "Banana", "Pear"};

    @Override
    public String next() {
        Random rand = new Random();
        return fruits[rand.nextInt(3)];
    }
}

泛型方法

不要混淆返回值为泛型的方法和泛型方法，二者不同
一个真正的泛型方法：
首先在public与返回值之间的必不可少，这表明这是一个泛型方法，并且声明了一个泛型T
这个T可以出现在这个泛型方法的任意位置
泛型的数量也可以为任意多个，如：

1
2
3

public <T, K> K showKeyName(Generic<T> container) {
    //something
}

1
2
3
4
5

public <T> T showKeyName(Generic<T> container) {
    System.out.println("container key :" + container.getKey());
    T test = container.getKey();
    return test;
}

类中也可以有泛型方法

1
2
3
4
5
6
7
8
9
10

public class Test1<T> {

    public void testMethod(T t) {
        System.out.println(t.getClass().getName());
    }

    public <T> T testMethod1(T t) {
        return t;
    }
}

泛型类中的类型参数T与泛型方法中的类型参数T是没有联系的，泛型方法始终以自己定义的类型参数为准

如果静态方法要使用泛型的话，必须将静态方法也定义成泛型方法

1
2
3
4
5
6
7
8
9
10
11

public class StaticGenerator<T> {
    /**
     * 如果在类中定义使用泛型的静态方法，需要添加额外的泛型声明（将这个方法定义成泛型方法）
     * 即使静态方法要使用泛型类中已经声明过的泛型也不可以。
     * 如：public static void show(T t){..},此时编译器会提示错误信息：
     * "StaticGenerator cannot be refrenced from static context"
     */
    public static <T> void show(T t) {

    }
}

通配符

<?>

• 被称作无限定的通配符
• 当<?>存在时，Collection对象失去add( )能力
• 即不能调用与类型有关的方法

<? extends T>

• 被称作有上限的通配符，以T为上界
• 对应集合丧失add( )能力
• 可以通过get( )返回元素，能用T以及T的父类接收
• 只能被T以及T就子类的集合赋值

<? super T>

• 被称作有下限的通配符，以T为下界
• 对应集合可以add( )T以及T的子类
• 可以通过get( )返回元素，但只能用Object接收
• 只能被T以及T的父类的集合赋值

泛型的上下边界添加，必须与泛型的声明在一起

泛型的声明：即在类名后的< >，泛型方法修饰符和返回值之间的< >

类型擦除

1
2
3

List<String> l1 = new ArrayList<String>();
List<Integer> l2 = new ArrayList<Integer>();
System.out.println(l1.getClass()==l2.getClass()); //true

类型擦除：泛型信息只存在于代码编译阶段，在进入 JVM 之前，与泛型相关的信息会被擦除掉

在泛型类被类型擦除的时候，之前泛型类中的类型参数部分如果没有指定上限，如 则会被转译成普通的 Object 类型，如果指定了上限如 则类型参数就被替换成类型上限String，并不存在的写法

List 一旦传入类型参数 List 就不能add(string)了，但基于对类型擦除的了解，其实T都是Object，可以利用反射绕开这个限制

1
2
3

public interface List<E> extends Collection<E> {
    boolean add(E e);
}

类型擦除后，add()方法等同于 boolean add(Object obj);

1
2
3
4
5
6
7
8
9
10

List<Integer> ls = new ArrayList<>();
ls.add(23);
//ls.add("text");
try {
    Method method = ls.getClass().getDeclaredMethod("add", Object.class);
    method.invoke(ls, "test");
    method.invoke(ls, 42.9f);
} catch (Exception e) {
    e.printStackTrace();
}

可以看到，利用类型擦除的原理，用反射的手段就绕过了正常开发中编译器不允许的操作限制

参考资料：
https://blog.csdn.net/s10461/article/details/53941091

享元模式

描述：通过共享以便有效的支持大量小颗粒对象。

享元模式可以避免大量非常相似类的开销，在程序设计中，有时需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本都是相同的，有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将他们传递进来，就可以通过共享大幅度减少单个实例的数目。

什么时候用享元模式？
如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以是外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式。

享元模式的4个角色

• Flyweight（抽象享元类）：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态），同时也可以通过这些方法来设置外部数据（外部状态）。

• ConcreteFlyweight（具体享元类）：它实现了抽象享元类，其实例称为享元对象；在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象。

• UnsharedConcreteFlyweight（非共享具体享元类）：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类；当需要一个非共享具体享元类的对象时可以直接通过实例化创建。

• FlyweightFactory（享元工厂类）：享元工厂类用于创建并管理享元对象，它针对抽象享元类编程，将各种类型的具体享元对象存储在一个享元池中，享元池一般设计为一个存储“键值对”的集合（也可以是其他类型的集合），可以结合工厂模式进行设计；当用户请求一个具体享元对象时，享元工厂提供一个存储在享元池中已创建的实例或者创建一个新的实例（如果不存在的话），返回新创建的实例并将其存储在享元池中。

以棋类运动为例，棋子可以看作抽象享元类，围棋棋子，五子棋棋子，象棋棋子这些可以看作是具体享元类。各类棋子除了具体位置(在此处以(x,y)坐标表示)这一外部状态不同，其他属性都相同。此时就可以使用享元模式，比如在一局围棋游戏中，只有黑棋和白棋这两种具体享元类，大大减少了重复生成棋子的内存开销。

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
34

//Flyweight
abstract class Piece {
    public abstract void setPosition(int x, int y);
}

//ConcreteFlyweight
class GoPieces extends Piece {
    private String type;

    public GoPieces(String type) {
        this.type = type;
    }

    @Override
    public void setPosition(int x, int y) {
        System.out.println(type + " 下在(" + x + "," + y + ")处。");
    }
}

//FlyweightFactory
class PieceFactory {
    private Map<String, Piece> pieceMap = new HashMap<>();

    public Piece getPiece(String key) {
        if (!pieceMap.containsKey(key)) {
            pieceMap.put(key, new GoPieces(key));
        }
        return pieceMap.get(key);
    }

    public int getNumberOfPiecesType() {
        return pieceMap.size();
    }
}

主程序

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

public class Flyweight {
    public static void main(String[] args) {
        PieceFactory pieceFactory = new PieceFactory();
        Piece black1 = pieceFactory.getPiece("黑棋");
        black1.setPosition(3, 4);

        Piece write1 = pieceFactory.getPiece("白棋");
        write1.setPosition(5, 6);

        Piece black2 = pieceFactory.getPiece("黑棋");
        black2.setPosition(1, 2);

        Piece write2 = pieceFactory.getPiece("白棋");
        write2.setPosition(3, 7);

        Piece black3 = pieceFactory.getPiece("黑棋");
        black3.setPosition(4, 8);

        System.out.println(pieceFactory.getNumberOfPiecesType());
    }
}

组合模式

描述：把多个对象组成树状结构来表示局部与整体，这样用户可以一样的对待单个对象和对象的组合。

组合模式要解决的是整体和部分可以被一致对待的问题

何时使用组合模式？
需求中是体现部分与整体层次的结构时，希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式。

组合模式的3个角色

• Component（抽象构件）：它可以是接口或抽象类，为叶子构件和容器构件对象声明接口，在该角色中可以包含所有子类共有行为的声明和实现。在抽象构件中定义了访问及管理它的子构件的方法，如增加子构件、删除子构件、获取子构件等。

• Leaf（叶子构件）：它在组合结构中表示叶子节点对象，叶子节点没有子节点，它实现了在抽象构件中定义的行为。对于那些访问及管理子构件的方法，可以通过异常等方式进行处理。

• Composite（容器构件）：它在组合结构中表示容器节点对象，容器节点包含子节点，其子节点可以是叶子节点，也可以是容器节点，它提供一个集合用于存储子节点，实现了在抽象构件中定义的行为，包括那些访问及管理子构件的方法，在其业务方法中可以递归调用其子节点的业务方法。

组合模式的关键是定义了一个抽象构件类，它既可以代表叶子，又可以代表容器，而客户端针对该抽象构件类进行编程，无须知道它到底表示的是叶子还是容器，可以对其进行统一处理。同时容器对象与抽象构件类之间还建立一个聚合关联关系，在容器对象中既可以包含叶子，也可以包含容器，以此实现递归组合，形成一个树形结构。

透明模式与安全模式

• 透明模式在Component中声明所有管理子对象的方法，这样做的好处是叶结点和枝结点对于外界没有区别，它们具备完全一致的行为接口，但Leaf本身不具备add()、remove()功能，所有实现它们是没有意义的。

• 安全模式在Component接口中不去声明管理子对象的方法，那么子类Leaf就不需要实现它们，而是在Composite中实现，不过由于不够透明，叶结点和枝结点有不同的接口，客户端调用时要做相应的判断。

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

//Component
abstract class Company {
    protected String name;

    public Company(String name) {
        this.name = name;
    }

    public abstract void add(Company company);

    public abstract void remove(Company company);

    public abstract void display(int depth);

    public abstract void work();
}

//Composite
class ConcreteCompany extends Company {
    private List<Company> companyList = new ArrayList<>();

    public ConcreteCompany(String name) {
        super(name);
    }

    @Override
    public void add(Company company) {
        companyList.add(company);
    }

    @Override
    public void remove(Company company) {
        companyList.remove(company);
    }

    @Override
    public void display(int depth) {
        for (int i = 0; i < depth; ++i) {
            System.out.print('-');
        }
        System.out.println(name);
        for (Company component : companyList) {
            component.display(depth + 2);
        }
    }

    @Override
    public void work() {
        for (Company component : companyList) {
            component.work();
        }
    }
}

//Leaf
class HRDepartment extends Company {
    public HRDepartment(String name) {
        super(name);
    }

    @Override
    public void add(Company company) {

    }

    @Override
    public void remove(Company company) {

    }

    @Override
    public void display(int depth) {
        for (int i = 0; i < depth; ++i) {
            System.out.print('-');
        }
        System.out.println(name);
    }

    @Override
    public void work() {
        System.out.println(name + " 员工招聘培训管理");
    }
}

class FinanceDepartment extends Company {
    public FinanceDepartment(String name) {
        super(name);
    }

    @Override
    public void add(Company company) {

    }

    @Override
    public void remove(Company company) {

    }

    @Override
    public void display(int depth) {
        for (int i = 0; i < depth; ++i) {
            System.out.print('-');
        }
        System.out.println(name);
    }

    @Override
    public void work() {
        System.out.println(name + " 公司财务收支管理");
    }
}

主程序

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

public class Composite {
    public static void main(String[] args) {
        ConcreteCompany root = new ConcreteCompany("北京总公司");
        root.add(new HRDepartment("总公司人力资源部"));
        root.add(new FinanceDepartment("总公司财务部"));

        ConcreteCompany comp = new ConcreteCompany("上海华东分公司");
        comp.add(new HRDepartment("华东分公司人力资源部"));
        comp.add(new FinanceDepartment("华东分公司财务部"));
        root.add(comp);

        ConcreteCompany comp1 = new ConcreteCompany("南京办事处");
        comp.add(new HRDepartment("南京办事处人力资源部"));
        comp.add(new FinanceDepartment("南京办事处财务部"));
        comp.add(comp1);

        root.display(1);
        root.work();
    }
}

代理模式

描述：为其他对象提供一个代理以控制对这个对象的访问。

代理模式的3个角色

• Subject（抽象角色）：通过接口或抽象类声明真实角色实现的业务方法。

• Proxy（代理角色）：实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并可以附加自己的操作。

• RealSubject（真实角色）：实现抽象角色，定义真实角色所要实现的业务逻辑，供代理角色调用。

代理模式又分为静态代理和动态代理

先来举个例子，电脑和手机都可以联网，现在有个代理VPN也可以联网，我们用VPN代理实现翻墙功能，用代码实现就是

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

//Subject
interface Networking {
    void connection();
}

//RealSubject
class Computer implements Networking {
    private String name;

    public Computer() {
    }

    public Computer(String name) {
        this.name = name;
    }

    @Override
    public void connection() {
        System.out.println(name + " 已联网，但访问网站受限。");
    }
}

class SmartPhone implements Networking {
    private String name;

    public SmartPhone() {
    }

    public SmartPhone(String name) {
        this.name = name;
    }

    @Override
    public void connection() {
        System.out.println(name + " 已联网，但访问网站受限。");
    }
}

//Proxy
class ComputerVPNProxy implements Networking {
    Computer computer;

    public ComputerVPNProxy(Computer computer) {
        this.computer = computer;
    }

    @Override
    public void connection() {
        computer.connection();
        System.out.println("已翻墙，开始网上冲浪吧！");
    }
}

此处用了静态代理的实现方式，可以看到实现起来非常简单，但有个缺点，如果我们不确定需要代理某个真实类的时候会比较麻烦，而且在类过多的时候，目标对象与代理对象都要维护，会使系统复杂度提升，维护起来也更加麻烦。这时我们就可以使用动态代理来进行解决。

这里记录两种动态代理的方式

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

//JDK动态代理
class DynamicVPNProxy implements InvocationHandler {
    private Networking networking;

    public DynamicVPNProxy(Networking networking) {
        this.networking = networking;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = null;
        if ("connection".equals(method.getName())) {
            result = method.invoke(networking, args);
        }
        System.out.println("已翻墙，开始网上冲浪吧！");
        return result;
    }
}


//cglib代理
class CglibVPNProxy implements MethodInterceptor {
    private Object target;//注意 target最好写一个无参构造方法

    public CglibVPNProxy(Object target) {
        this.target = target;
    }

    public Object getVPNInstance() {
        //1工具类
        Enhancer en = new Enhancer();
        //2设置父类
        en.setSuperclass(target.getClass());
        //3设置回调函数
        en.setCallback(this);
        //4创建子类(代理对象)
        return en.create();
    }

    @Override
    public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
        Object result = null;
        if ("connection".equals(method.getName())) {
            result = method.invoke(target, objects);
        }
        System.out.println("已翻墙，开始网上冲浪吧！");
        return result;
    }
}

主程序

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

public class Proxy {
    public static void main(String[] args) {
        Computer computer = new Computer("IBN-5100");
        computer.connection();

        //静态代理
        Networking computerVPN = new ComputerVPNProxy(computer);
        computerVPN.connection();

        //JDK动态代理
        Networking smartPhoneVPN = (Networking) java.lang.reflect.Proxy.newProxyInstance(ClassLoader.getSystemClassLoader(),
                new Class[]{Networking.class}, new DynamicVPNProxy(new SmartPhone("IPhoneX")));
        smartPhoneVPN.connection();

        //Cglib动态代理
        Networking smartPhoneVPN1 = (Networking) new CglibVPNProxy(new SmartPhone("MI6")).getVPNInstance();
        smartPhoneVPN1.connection();
    }
}

参考资料：

• https://blog.csdn.net/wwwdc1012/article/category/7152423
• 《大话设计模式》

什么是Netty

网上很多文章都有作解释。以作者的使用体验来说，Netty是封装了 Java socket nio 来进行网络编程的工具。说到网络编程，大二软工的软件工程实训就有这个小课题，当时作者是用Java socket io来写，还没用到nio呢，就是参照网上的例子手动模拟通信过程，自己用最简单的 阻塞I/O 的模式写了一个Thread类来处理所有不同种类的请求，由于需求简单，尚能完成。 想要模拟效果更自然一点就要用 非阻塞I/O 模式，而nio就是用来写非阻塞I/O的api。但是nio的编写对java程序员是有比较高的要求的。Netty就可以简化这一系列操作。

预备知识

贴几个比较靠谱的博客，不求甚解，大致了解一下就好。
关于NIO：
https://www.jianshu.com/p/3cec590a122f (推荐，也包括I/O模型)
https://my.oschina.net/andylucc/blog/614295
关于I/O模型：
https://segmentfault.com/a/1190000003063859

开发环境

java JDK1.8 + IDEA + maven + Netty 4.1.6
maven依赖：

1
2
3
4
5

<dependency>
           <groupId>io.netty</groupId>
           <artifactId>netty-all</artifactId>
           <version>4.1.6.Final</version>
</dependency>

实现功能

C/S通信：C是客户端，S是服务端。在IDEA控制台开启服务端接收客户端的信息String, 并返回一个“hi!”+String，客户端收到服务端的信息后在控制台上输出。

代码讲解

分为服务端和客户端两部分，各自又有一个处理连接逻辑的代码

服务端代码

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.ChannelPipeline;
import io.netty.channel.EventLoopGroup;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.handler.codec.DelimiterBasedFrameDecoder;
import io.netty.handler.codec.Delimiters;
import io.netty.handler.codec.string.StringDecoder;
import io.netty.handler.codec.string.StringEncoder;


public class EchoServer {
    private final int port;  //1.设置服务端端口

    public EchoServer(int port) {
        this.port = port;
    }

    public void start() throws Exception {
        EventLoopGroup group = new NioEventLoopGroup();  //2.创建 EventLoopGroup
        try{
            /*
             * 客户端的是Bootstrap，服务端的则是    ServerBootstrap。
             **/
            ServerBootstrap sbs = new ServerBootstrap();  //3.创建 ServerBootstrap
            sbs.group(group)
                    .channel(NioServerSocketChannel.class)  //4.指定使用 NIO 的传输 Channel
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) throws Exception {
                            ChannelPipeline ph = ch.pipeline();
                            /*
                            * Netty中的编码/解码器，通过他你能完成字节与pojo、pojo与pojo的相互转换，
                            * 从而达到自定义协议的目的。
                            * 下面是以("\n")为结尾分割的 解码器
                            * */
                            ph.addLast("framer", new DelimiterBasedFrameDecoder(8192, Delimiters.lineDelimiter()))
                                    .addLast("decoder", new StringDecoder())
                                    .addLast("encoder", new StringEncoder())  //解码和编码，应和客户端一致
                                    .addLast("handler", new EchoServerHandler());  //5.添加 EchoServerHandler 到 Channel 的 ChannelPipeline

                        }
                    });

            ChannelFuture cf = sbs.bind(this.port).sync();  //6.设置socket地址使用所选的端口 并且 绑定的服务器，sync 等待服务器关闭

            System.out.println("服务端启动成功...");

            cf.channel().closeFuture().sync();  //7.关闭 channel 和 块，直到它被关闭

        }finally {
            group.shutdownGracefully();  //8.关闭 EventLoopGroup，释放所有资源
        }
    }

    public static void main(String[] args) throws Exception{
        new EchoServer(65535).start();
    }
}

注意这一段代码：

这是关键所在，其余代码基本上是套路代码，按部就班写就可以。
关键在于此处出现了：

• 用ChannelPipeline引用了SocketChannel的pipeline，原因在于ChannelPipeline是用于存放ChannelHandler的容器，而接下来的解码编码操作和自定义的逻辑处理类都要涉及到ChannelHandler的子类
  它们之间的关系可以用下图表示：

• Encoder(编码器)和Decoder(解码器)，属于Codec框架的内容，大致意思是：此处描述了服务端和客户端之间传输了什么类型的数据，这里要传输String就用到了StringDecoder/Encode 当然也可以传输其他类型的数据，详情参考这篇博客：https://www.jianshu.com/p/fd815bd437cd

• 注释5.处的EchoServerHandler是自定义的类，可以看作是一种“规则”，规定了服务端以什么方式处理客户端发来的数据。

服务端处理连接的代码

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

import java.net.InetAddress;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.SimpleChannelInboundHandler;

public class EchoServerHandler extends SimpleChannelInboundHandler<String> {
    /*
     * 收到消息时，返回信息
     */
    @Override
    protected void channelRead0(ChannelHandlerContext ctx, String msg)
            throws Exception {
        System.out.println("服务端接受的消息 : " + msg);  // 收到消息直接打印输出
        if("quit".equals(msg)){  //服务端断开的条件
            ctx.close();
        }
        ctx.writeAndFlush("hi! "+msg+"\n");  // 返回客户端消息
    }
    /*
     * 建立连接时，返回消息
     */
    @Override
    public void channelActive(ChannelHandlerContext ctx) throws Exception {
        System.out.println("连接的客户端地址:" + ctx.channel().remoteAddress());
        ctx.writeAndFlush("客户端"+ InetAddress.getLocalHost().getHostName() + "成功与服务端建立连接！ \n");
        super.channelActive(ctx);
    }
}

客户端代码

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76