Guava之于Javaer，如同Excel之于办公达人。
都非常好用，但实际上大部分人只用到了其1%不到的功能。
敏感信息脱敏实际上是隶属于安全领域的一个子领域，而日志脱敏又是敏感信息脱敏的一个子领域。
好了，打住，不闲聊这些有的没的，直接开整：到底什么是日志脱敏？
1.1 未脱敏之前
如下有一个关于个人信息的类
在日志脱敏之前，我们一般会这样直接打印日志
然后打印完之后，日志大概是这样
如下：需要把敏感字段中的一部分字符使用特殊符号替换掉（这里我们用来做特殊符号）
所以，很自然的，我们就写了个脱敏组件，在每一个字段上用注解来标识每一个字段是什么类型的敏感字段，需要怎么脱敏。
比如，对于上面的个人信息，在打印日志的时候需要研发人员做两件事：
使用脱敏组件提供的注解来标识敏感字段
使用脱敏组件先脱敏，再打印日志
如下，先使用脱敏组件提供的工具类脱敏个人信息，然后再打印日志
具体的使用和实现原理可以参考：
https://github.sheincorp.cn/vipshop/vjtools/blob/master/vjkit/docs/data_masking.md
到了企业里面，你得满足客户（也就是研发人员）奇奇怪怪（也许只是一开始你觉得是奇奇怪怪，但是实际上很合理）的需求。 比如，我们就有研发人员提出：需要按照Map中的Key来配置脱敏规则
啥意思呢？简单来说，如果我有一个Map类型的数据，如下
那么在配置文件中指定好对应的key的脱敏规则后就可以把Map中的敏感数据也脱敏。
大概配置文件如下：
那先不管需求是否合理吧，反正客户就是上帝，满足再说。
然后，我们就开始实现了。
基本思路：复制Map，然后遍历复制后的Map,找到Key有对应脱敏规则的value，按照脱敏规则脱敏，最后使用Json框架序列化脱敏后的Map。
2分钟
我们直接看问题。有使用我们这个组件的研发人员找过说:我c a o，你们把我的业务对象Map中的值修改掉了。
我们本来想直接回怼：你们是不是姿势不对，不会用啊。但是本着严(zhi)谨(qian)的(bei)原(da)则(nian)(guo)，还是问了句，你在本地复现了吗？
我们发现：有嵌套类型的Map的时候就会有问题
测试程序如下：
输出结果如下：
虽然问题很大，但是我们还是要沉着应对问题，仔细分析问题。做到泰山崩于前而色不变，才是打工人的正确处事方式。不然只会越急越慌，越慌越不冷静，最后买1送3（修1个bug，新引入3个bug）
简单debug，加上看源代码，其实这个问题还是比较容易发现的，主要问题就是在复制Map对象的姿势不对
如下，我们是使用这样的方式来复制Map的。本来是想做深度clone的，但是这种事做不到深度clone的。对于有内嵌的对象的时候只能做到浅clone。
所以，只有一层关系的简单Map是可以脱敏成功的，且不会改变原来的Map。但是对于有嵌套的Map对象时，就会修改嵌套Map对象中的值了。
从上面的分析中就可以得出其根本原因：没有正确地深度clone Map对象
那很自然地，我们的解决思路就是找到一种合适的深度 clone Map对象的方式就OK了。
然后我就问ChatGPT了，ChatGPT的回答有下面几个方法
使用序列化和反序列化： 通过将对象序列化为字节流，然后再将字节流反序列化为新的对象，可以实现深度克隆。需要注意被克隆的对象及其引用类型成员变量都需要实现Serializable接口。
使用第三方库： 除了上述两种方式，还可以使用一些第三方库，例如Apache Commons的SerializationUtils类、Google的Gson库等，它们提供了更简洁的方法来实现深度克隆。
使用JSON序列化和反序列化： 将对象转换为JSON字符串，然后再将JSON字符串转换为新的对象。需要使用JSON库，如Jackson、Gson等。
使用Apache Commons的BeanUtils类： BeanUtils提供了一个cloneBean()方法，可以对JavaBean进行深度克隆。需要注意，被克隆的对象及其引用类型成员变量都需要实现Serializable接口。
最佳实践是根据需求和具体情况灵活应用，或者采用第三方库实现对象克隆，如 Apache Commons BeanUtils、Spring BeanUtils 等。
上面几个方式基本上可以分为3类：
序列化和反序列化： JDK自带的序列化（需要实现Serializable接口）；利用Gson,FastJson,Jackson等JSON序列化工具序列化后再反序列化；其他序列化框架序（如Hessain等）列化反序列化
利用第三方库： 第三方库直接clone对象。但都有一定的限定条件
视情况而定： 基本上没有一种通用的方法，可以适配是有的深度clone场景。所以ChatGPT提出了这一种不是办法的办法
然后就是卡卡一顿猛敲，如下：常规递归操作
好的，我懂的。咱看到这，图的就是一个乐，你让我思考，这不是强人所难吗
思考，思考是不可能存在的。
那咱们就直接看问题：就是啥都好，问题就是性能比较差！！！
如果你是一个老司机，你可能看到上面的代码就已经感觉到了，性能是相对比较低的。
基本上，Map层级越深，字段越多，内嵌的集合对象元素越多，性能越差!!!
至于差到什么程度，其实是可以通过 微基准测试框架JMH来实际测试一下就知道了。这里我就不测试了。
那我们还有什么办法来解决这个性能问题吗？
如果我们还是集中于深度clone对象上做文章，去找寻性能更高的深度clone框架或者是类库的话，那么其实这个问题就已经走偏了。
我们再来回顾一下我们之前的问题:
我们需要对Map对象按照key来脱敏,所以我们选择了深度clone Map，然后对Map遍历按照key脱敏后序列化。
那其实我们最终要解决的问题是：Map对象序列化后的字符串得是按照key的脱敏规则脱敏后的字符串。
所以，其实我们除了深度clone这一条路外，还有另外两条路：
自定义Map类型的序列化器：在序列化Map的时候，如果有脱敏规则则应用脱敏规则来序列化Map
转换Map为脱敏后的Map：自定义Map对象，将脱敏规则作为转换函数来把普通的Map转换为脱敏的Map
对于第一种方式，要看你使用的Json框架是否支持（一般Map类型用的都是内置的Map序列化器，不一定可以自定义）。 那第二种方式，到底应该如何玩呢. 如下：
如上，Map不再是clone的玩法，而是转换的玩法，所以，这种操作是非常轻量级的。
但是这种玩法也有缺点：比较麻烦，需要override好多方法（不然就需要熟读Map序列化器来找到最小化需要override的方法，并且不太靠谱），并且全部都要是转换的玩法。
Returns a view of a map whose values are derived from the original map's entries. In contrast to transformValues, this method's entry-transformation logic may depend on the key as well as the value. All other properties of the transformed map, such as iteration order, are left intact.
返回一个Map的试图，其中它的值是从原来map中entry派生出来的。相较于transformValues方法，这个基于entry的转换逻辑是既依赖于key又依赖于value。变换后的映射的所有其他属性（例如迭代顺序）均保持不变
这不正是我们上面需要实现的 MaskMap吗！！！
那脱敏的地方只要转换一下Map就可以了，如下：
我们调用了transformEntries方法，是可以根据key（可以找到脱敏规则）和value（可以判断类型）来转换的。但是Map中的有些API实际上可能只有value（比如）或者只有key(比如get()方法)的，那这种是如何生效的？
你是不是有那么一点好奇呢？
我们就不去想了，直接看代码：
对于方，只有key参数：
但是比较容易通过key拿到对应的value，然后把key和value传给转换函数就可以了
这里的实现其实有一个细节，不知道大家注意没有。
就是这一个判断：，我们上面实现的时候直接没有考虑到值为null的情况（但value为null,但是有对应的key的时候还是应该要调用转换函数的）
对于方，只返回值
也是一样，返回一个转换后的 Collection，其中Collection中的值也是经过 transformer转换的。
而对于迭代器也是一样的，都有对应的实现类把转换逻辑放进去了。
6.1. Guava的Veiw思想
其实上面的这种 Veiw的基本思想，在Guava中有非常多的场景应用的，如
com.google.common.base.Splitter#split
com.google.common.collect.Lists#partition
com.google.common.collect.Sets#difference
...other
这种 Veiw 的基本思想，其实就是懒加载的思想：在调用的时候不实际做转换，而是在实际使用的时候会做转换
比如：在调用的时候实际上并不是立刻马上去分隔字符串，而是返回一个Iterable的View对象。只是在实际迭代这个Iterable的View对象时才会实际去切分字符串。
在比如在调用的时候并不会立刻马上去做两个集合的差操作，而是返回一个 SetView的View对象,只有在实际使用这个View对象的API的时候才会真正做差操作。
注意点：这种思想大部分场景下，会是性能友好型的，但是也有例外。我们要分清楚场景。
比如，分割字符串的方法，如果调用完之后不做任何操作，或者只会遍历一次（大部分场景都是只遍历一次），那么这其实就是最好的方法。但是如果调用完之后，还需要遍历很多次，那么这种场景下，性能可能不是最好的。
所以，对于我们来讲，如果Guava工具包中没有我们需要的View的方法，那么我们可以自己按照这个思想来造一个。如果已经有了，要区分场景使用.
6.2. 简单聊一下Guava API的兼容性
升级过Guava版本的同学可能深有体会，升级Guava是一件比较头疼的事情。因为Gauva API的兼容性是做得很差的。（当然这里主要还是因为大部分同学没有认真阅读官方的文档导致的）
所以对于做组件的同学，对于Guava的使用一定要慎重：能不用就不用，必须要用的话一定不能使用以@Beta注解标注的方法或者类。
Gauva确实是一个保藏库，当你要造轮子的时候不妨先看看Gauva中有没有现成的轮子。每看一次，也许就多一次惊喜。
这一次是Map对象脱敏场景遇上了Guava的 ，那么你又有什么场景偶遇了Guava呢？，可以在评论区聊一下。