尚弟的小笔记

一个特殊字符与一下午

Tue, 23 May 2023 00:00:00 +0000

今天是这个迭代的最后一周。本来这个迭代工作交付还是比较顺利的，除了个别几个联调的需求，大家都在收尾解bug了。

我最后一个bug是一个多语问题，有一个奇怪的情况是我配置了五百多个多语，但是只有其中一组，共5个多语有问题：其它文字在切换语言后都能换过来，只有这些文字还是中文。

可是这并不应该呀？因为我那么多多语，配置的时候都不是手动操作的，肯定是通过程序生成后批量导入的。出问题的这一组多语，无论是输入源——同一组元数据的描述，还是程序——被用来生产所有的多语key，其逻辑是相同的。

多语的key生成规则也很简单，就是产生一组类似A.B.C.{D}的key，其中的D来自元数据的描述。而且我从我导入的文件里找到有关的key，拿到多语平台里，也能找到到。这么奇怪的事情，我前后查了一个小时，做了多次尝试，仍然不得头脑。最后拉上元数据，多语平台的同事一起研究了一下午，大家都没有发现问题在哪里。

但是排查过程中有个奇怪的情况引起了我的注意。有一位同事尝试重新拼凑了问题的多语key，到多语平台里搜索，完全搜不到。嗯？我这里都是正常的啊，我把key发给其他同事，导入的文件也发给其他同事，大家都能搜到。应该是这个同事自己拼凑的时候打错了字母了吧？

但是恰好就是这段搜不到的key才让大家找到了真正的问题。有问题的同事将key发到群里，大家发现key跟多语平台里的key的字母完全一样。有经验的人应该立刻能发现问题了，那就是key里带有不可见的零宽字符。于是我们用getBytes分析，发现问题字符串里A.B.C.后多了三个字符，0xe2808d。这个字符在Unicode代码里是一个emoji符号，但是它表示的是零宽的连接符。什么意思呢？就是它显示的时候会将前后的emoji表情连起来，但是它单独出现的时候，是没有宽度的。比如，👨👩👦中间用这个零宽的字符间隔开，就是👨‍👩‍👦。其它emoji也可以用这个字符连接起来，但是效果并不像这三个头像那么神奇，可以合并成一个等宽的emoji表情（这个效果取决于大家设备对emoji的支持，至少在Windows11上效果比较好）。

这个连接符是怎么来的呢？原来是有人编辑文档的时候不小心粘贴进去了这个字符，并且由于它不可见，因此我写程序的时候也不慎粘贴到代码里，被生成了这一组有问题的key的生成。

最后编辑好文档，重新生成key导入，bug解决。一下午也就随着bug消失了。

Java8Stream用法整理

Sun, 30 Apr 2023 00:00:00 +0000

平常经常在用Stream，但是很少全面的整理一下用法。今天是基于Java8版本对Stream的用法进行了整理。

Stream是Java8提供的一个接口，主要定义了一种流式处理数据的方式。它扩展自接口BaseStream。所以讲Stream的用法，先要简单说一下BaseStream的用法。

BaseStream

BaseStream 接口提供了如下能力：

iterator 返回一个迭代器，可以用于遍历流中的元素。

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Iterator<Integer> iterator = numbers.stream().iterator();
while(iterator.hasNext()) {
    System.out.println(iterator.next()); 
}

输出结果是

spliterator 返回一个分割器Spliterator，可以用于将流分成若干个部分进行并行处理。这个方法对于使用者来说基本没什么用。

1
2

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Spliterator<Integer> spliterator = numbers.stream().spliterator();

isParallel 判断流是否是并行流。

1
2
3

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
boolean isParallel = numbers.stream().parallel().isParallel();
System.out.println(isParallel); // true

sequential 将并行流转换为顺序流。

1
2

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Stream<Integer> sequentialStream = numbers.stream().parallel().sequential();

parallel 将顺序流转换为并行流。

1
2

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Stream<Integer> parallelStream = numbers.stream().parallel();

unordered 返回一个无序流。

1
2

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Stream<Integer> unorderedStream = numbers.stream().unordered();

注意，它的含义并不是把流变成无序的，只是将流的有序约束关闭了。也就是说，现在输出这个stream的内容，仍然是1,2,3,4,5

onclose 在关闭流之前执行一个操作。

1
2
3

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Stream<Integer> stream = numbers.stream().onClose(() -> System.out.println("Stream closed."));
stream.close();//Stream closed.

close 关闭流，释放流占用的资源。

1
2
3

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);
Stream<Integer> stream = numbers.stream();
stream.close();

Stream

我们再看一下Stream的用法：

allMatch 判断所有元素是否都满足给定的条件。示例：

        List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            boolean allEven = numbers.stream().allMatch(n -> n % 2 == 0);
            System.out.println("All even? " + allEven);

            boolean allGreaterThanZero = numbers.stream().allMatch(n -> n > 0);
            System.out.println("All greater than zero? " + allGreaterThanZero);

结果：

1
2

All even? false
All greater than zero? true

anyMatch 判断是否存在至少一个元素满足给定的条件。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            boolean anyEven = numbers.stream().anyMatch(n -> n % 2 == 0);
            System.out.println("Any even? " + anyEven);

            boolean anyNegative = numbers.stream().anyMatch(n -> n < 0);
            System.out.println("Any negative? " + anyNegative);

结果：

1
2

Any even? true
Any negative? false

builder 创建一个Stream.Builder，可以用于构建一个Stream。示例：

            Stream.Builder<Integer> builder = Stream.builder();

            builder.add(1);
            builder.add(2);
            builder.add(3);

            Stream<Integer> stream = builder.build();
            stream.forEach(System.out::println);

结果：

1
2
3

1
2
3

collect 将Stream中的元素收集到一个结果容器中。Collector是一个接口，可以自定义收集器。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            List<Integer> evenNumbers = numbers.stream()
                .filter(n -> n % 2 == 0)
                .collect(Collectors.toList());

            System.out.println("Even numbers: " + evenNumbers);

结果：

`1`	`Even numbers: [2, 4, 6, 8, 10]`

concat 合并两个Stream，返回一个新的Stream。示例：

            List<Integer> numbers1 = Arrays.asList(1, 2, 3);
            List<Integer> numbers2 = Arrays.asList(4, 5, 6);

            Stream<Integer> stream1 = numbers1.stream();
            Stream<Integer> stream2 = numbers2.stream();

            Stream<Integer> combinedStream = Stream.concat(stream1, stream2);

            combinedStream.forEach(System.out::println);

结果：

count 返回Stream中元素的个数。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            long count = numbers.stream().count();
            System.out.println("Count: " + count);

结果：

`1`	`Count: 10`

distinct 返回一个去重后的Stream。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 2, 3, 3, 3, 4, 4, 4, 4);

            List<Integer> distinctNumbers = numbers.stream().distinct().collect(Collectors.toList());
            System.out.println("Distinct numbers: " + distinctNumbers);

结果：

`1`	`Distinct numbers: [1, 2, 3, 4]`

empty 创建一个空的Stream。示例：

1
2

            Stream<String> emptyStream = Stream.empty();
            emptyStream.forEach(System.out::println);

结果：

filter 对Stream中的元素进行筛选，返回符合条件的元素组成的新的Stream。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            List<Integer> evenNumbers = numbers.stream().filter(n -> n % 2 == 0).collect(Collectors.toList());
            System.out.println("Even numbers: " + evenNumbers);

结果：

`1`	`Even numbers: [2, 4, 6, 8, 10]`

findAny 返回任意一个元素。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            Optional<Integer> anyEvenNumber = numbers.stream().filter(n -> n % 2 == 0).findAny();
            System.out.println("Any even number: " + anyEvenNumber.get());

结果：

`1`	`Any even number: 2`

findFirst 返回第一个元素。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            Optional<Integer> firstEvenNumber = numbers.stream().filter(n -> n % 2 == 0).findFirst();
            System.out.println("First even number: " + firstEvenNumber.get());

结果：

`1`	`First even number: 2`

flatMap 将Stream中的元素映射为一个Stream，将所有Stream中的元素合并成一个Stream。示例：

            List<List<Integer>> numbers = Arrays.asList(
                Arrays.asList(1, 2, 3),
                Arrays.asList(4, 5, 6),
                Arrays.asList(7, 8, 9)
            );

            Stream<Integer> flatStream = numbers.stream().flatMap(List::stream);

            flatStream.forEach(System.out::println);

结果：

flatMapToDouble 将Stream中的元素映射为一个DoubleStream，将所有DoubleStream中的元素合并成一个DoubleStream。
flatMapToInt 将Stream中的元素映射为一个IntStream，将所有IntStream中的元素合并成一个IntStream。
flatMapToLong 将Stream中的元素映射为一个LongStream，将所有LongStream中的元素合并成一个LongStream。
forEach 对Stream中的每个元素执行给定的操作。示例：

1
2
3

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            numbers.stream().forEach(System.out::println);

结果：

forEachOrdered 对Stream中的每个元素按顺序执行给定的操作。示例：

            List<Integer> numbers = Arrays.asList(2, 1, 3, 5, 4);

            System.out.println("Output in original order:");
            numbers.stream().forEachOrdered(System.out::println);

            System.out.println("Output in sorted order:");
            numbers.stream().sorted().forEachOrdered(System.out::println);

结果：

Output in original order:
2
1
3
5
4
Output in sorted order:
1
2
3
4
5

generate 生成一个无限长度的Stream，其中每个元素由Supplier提供。示例：

1
2

            Stream<String> stream = Stream.generate(() -> "hello").limit(3);
            stream.forEach(System.out::println);

结果：

1
2
3

hello
hello
hello

iterate 生成一个无限长度的Stream，其中第一个元素由seed提供，后续元素由指定的函数f生成。示例：

1
2

            Stream<Integer> stream = Stream.iterate(1, n -> n + 1).limit(10);
            stream.forEach(System.out::println);

结果：

limit 截取Stream中的前maxSize个元素，返回一个新的Stream。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);

            List<Integer> firstThree = numbers.stream().limit(3).collect(Collectors.toList());
            System.out.println("First three numbers: " + firstThree);

结果：

`1`	`First three numbers: [1, 2, 3]`

map 对Stream中的元素进行映射，将每个元素转换为另一个元素。示例：

            List<String> words = Arrays.asList("hello", "world", "java");

            List<Integer> wordLengths = words.stream().map(String::length).collect(Collectors.toList());
            System.out.println("Word lengths: " + wordLengths);

结果：

`1`	`Word lengths: [5, 5, 4]`

mapToDouble 将Stream中的元素映射为double类型。
mapToInt 将Stream中的元素映射为int类型。
mapToLong 将Stream中的元素映射为long类型。
max 返回Stream中的最大元素。示例：

            List<Integer> numbers = Arrays.asList(2, 4, 6, 8, 10);

            Optional<Integer> maxNumber = numbers.stream().max(Integer::compare);
            System.out.println("Max number: " + maxNumber.get());

结果：

`1`	`Max number: 10`

min 返回Stream中的最小元素。示例：

            List<Integer> numbers = Arrays.asList(2, 4, 6, 8, 10);

            Optional<Integer> minNumber = numbers.stream().min(Integer::compare);
            System.out.println("Min number: " + minNumber.get());

结果：

`1`	`Min number: 2`

noneMatch 判断所有元素是否都不满足给定的条件。示例：

            List<Integer> numbers = Arrays.asList(1, 3, 5, 7, 9);

            boolean noneEven = numbers.stream().noneMatch(n -> n % 2 == 0);
            System.out.println("None even? " + noneEven);

            boolean noneNegative = numbers.stream().noneMatch(n -> n < 0);
            System.out.println("None negative? " + noneNegative);

结果：

1
2

None even? true
None negative? true

of 创建一个包含指定元素的Stream。示例：

1
2

            Stream<String> stream = Stream.of("apple", "banana", "cherry");
            stream.forEach(System.out::println);

结果：

1
2
3

apple
banana
cherry

peek 对Stream中的每个元素执行给定的操作，返回一个新的Stream。示例：

            List<Integer> numbers = Arrays.asList(2, 4, 6, 8, 10);

            List<Integer> doubledNumbers = numbers.stream()
                .peek(n -> System.out.println("Before doubling: " + n))
                .map(n -> n * 2)
                .peek(n -> System.out.println("After doubling: " + n))
                .collect(Collectors.toList());

            System.out.println("Doubled numbers: " + doubledNumbers);

结果：

Before doubling: 2
After doubling: 4
Before doubling: 4
After doubling: 8
Before doubling: 6
After doubling: 12
Before doubling: 8
After doubling: 16
Before doubling: 10
After doubling: 20
Doubled numbers: [4, 8, 12, 16, 20]

reduce 通过指定的累加器函数对Stream中的元素进行归约。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

            int sum = numbers.stream().reduce(0, (a, b) -> a + b);
            System.out.println("Sum: " + sum);

            int product = numbers.stream().reduce(1, (a, b) -> a * b);
            System.out.println("Product: " + product);

结果：

1
2

Sum: 15
Product: 120

skip 跳过Stream中的前n个元素，返回一个新的Stream。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

            List<Integer> skippedNumbers = numbers.stream().skip(2).collect(Collectors.toList());
            System.out.println("Skipped numbers: " + skippedNumbers);

结果：

`1`	`Skipped numbers: [3, 4, 5]`

sorted 对Stream中的元素进行排序，返回一个新的Stream。示例：

            List<Integer> numbers = Arrays.asList(2, 1, 3, 5, 4);

            List<Integer> sortedNumbers = numbers.stream().sorted().collect(Collectors.toList());
            System.out.println("Sorted numbers: " + sortedNumbers);

结果：

`1`	`Sorted numbers: [1, 2, 3, 4, 5]`

toArray 将Stream中的元素转换为一个数组。示例：

            List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5);

            Integer[] array = numbers.stream().toArray(Integer[]::new);
            System.out.println("Array: " + Arrays.toString(array));

结果：

`1`	`Array: [1, 2, 3, 4, 5]`

tcpdump排查现网问题两例

Wed, 29 Mar 2023 00:00:00 +0000

最近遇到了一件郁闷的事情，服务本身指标都正常，唯独搜索会超时，经过排查，非常明确是 ES 的 client 在发出 HTTP 请求以后，超时导致了用户结果异常。

本以为把问题反馈给运维就能找到问题，没想到运维一番查找，ES没有任何慢查询。这下问题就麻烦了，我服务 GC 正常，内存 CPU 都有不少余裕，pod 的 CPU 也没受到限制，网络流量正常，但是怎么证明我就是监控上上报的时候请求就发出去了，而不是在 client 里排队呢？

恰好同期也发生了一例 PG 查询缓慢的情况，我们超时信息是Druid的插件统计，得到偶尔耗时高达9-10秒，甚至25秒超时，而实际explain的时候扫描的行数却只有几十行的情况。这一次DBA也说没有发生慢查询，并且给出了 PG 的日志，显示请求后很快由请求方取消了请求，取消请求的时间与我服务里Druid超时的时间一致，建议我们排查Druid发出请求的池是否堵塞了。

还好我们有较为公正客观的标准，网络流量。所以处理也很简单，继续 tcpdump 走起！

由于这个流向是从服务器到 PG 服务器，因此我将接口流量导入到一个单独的环境，一天一千多请求，抓包处理很简单。采用的命令是 tcpdump -i eth0 -C 1000 'src host $currentIP and dst port 5432' -w debug.cap，-i的含义是采集 eth0 网卡上，从 currentIP 机器发出的，目标端口是 5432 的数据包，-C表示采集1G的数据。不需要应答是因为pg也没有及时应答，而且DBA也有明确的取消请求的时间点。

结果开始后没几分钟就抓到了问题请求：

看图可知，当时10点45分31秒就已经发出了请求，但是DBA经查，该请求确实是10点45分56秒在PG被请求方取消了。后来经过DBA分析，原来问题是SQL语句的扫描数据行比较少，但是索引有问题，hints高达160万，超时的时候是PG从磁盘加载数据所致。因此当第二次，第三次请求的时候，通常只需要几十毫秒。因此优化索引后，问题消失了。

至于ES的问题，我们采用了 tcpdump -i any host $currentIP or $destIP -G 7200 -w /opt/tomcat/temp/tcp-%Y_%m%d_%H%M_%S.cap -s 512。这个命令是表示每7200秒记录一个文件，-s 表示抓到的包只保留512字节。最终我们抓到了如下的情况：

可以看到我们22点09分55秒已经发出了请求，但是ES确实是在22点10分11秒才返回结果。对于这样的结果，运维表示还要在宿主机上抓包去分析，希望能尽快发现到底是网络问题，还是ES本身的问题。

浅谈Java开发中Redis的使用姿势

Tue, 28 Feb 2023 00:00:00 +0000

Redis是我们开发时最常使用的键值存储工具了，但是与诸多软件工具一样，它也有很多技巧和经验。本文就是将我了解的一些经验和教训分享出来。

使用建议

如果不谨慎使用Redis，可能浪费大量的内存，甚至性能低下。以下时使用时的几个具体建议：

命名规范

通常一个Redis实例有16个数据库，通常你的业务并不是独立的数据库。为了与其它业务避免冲突，通常会用前缀后缀做一些区分，比如"业务名称:原始key"作为真正存储的key。但是要注意的是，Key本身是字符串，Redis的底层数据结构是SDS。从Redis3.2开始，key长度增长时，SDS占用内存空间也会增加，所以Key的长度我们要适当控制。SDS 结构中的字符串长度和元数据大小的对应关系如下表所示：

字符串大小（字节）	SDS结构元数据大小（字节）
1~(2^5-1)	1
(2^5)~(2^8-1)	1
(2^8)~(2^16-1)	1
(2^16)~(2^32-1)	1
(2^32)~(2^64-1)	1

避免使用 bigkey

Redis效率如此高的一个原因是，它是单线程服务的模型。如果有bigkey，读写的时候就会阻塞线程，降低redis的处理效率。bigkey有两种情况：

键值对的值本身就很大，超过了1MB。这通常需要业务把存储的value降低到10k以下，可以采取数据压缩的办法来减少内存占用
键值对的值是集合类型，而集合的元素非常多。需要业务将value控制在1万以下比较适合，必要的话就拆分集合

使用高效的序列化和压缩方法

Java有多种序列化方式，比如protostuff和kryo，比Java内置的序列化方法更高效。有时候业务还会使用XML或者JSON存储。有时候为了避免XML和JSON的体积过大，可以使用snappy或者gzip压缩后再存入Redis，可以减少60%的内存占用

使用整数对象共享池

Redis内部维护了0-9999共一万个整数对象，并且把这一万个整数作为一个共享池使用。但是也有两种情况无法使用共享池：

如果Redis设置了maxmemory，而且开启了LRU策略（allkeys-LRU或者volatile-LRU），就无法使用共享池，因为无法判断LRU了
如果集合类型的数据采用ziplist编码，而集合元素是整数u，也不能使用共享池，因为ziplist使用了紧凑的内存结构，判断整数对象的共享情况效率低下

利用Hash优化缓存

如果是同一个实体的多个属性做缓存，用同一个key的hash来存储，可以减少额外的元数据占用

尽可能减少存储的数据量

不论是string，List，Set还是Zset，底层实现都是多样的。Redis会根据数据结构中的数据量做动态调整。比如字符串，如果是少于20的整数，会直接存储在指针里；小于等于44的字符串会存储在一段连续的44长度的内存。如果你存储在这些结构里的数据量少于阈值，就可以采用更简单高效的数据结构，从而带来一定的收益。

只用来保存热数据

Redis使用的是最昂贵的内存进行存储，RDB和AOF日志持久化保存数据都只是提供数据可靠性保障的，并不能扩充容量。因此业务最好只存储热点数据。

不同的业务数据分实例存储

即便我们采用前缀的方式区分了存储的key，但是如果两个大量访问的业务都存储在同一个实例上，还是会对Redis的性能产生影响。因此最好不同的业务将数据存储在不同的Redis实例上。

数据保存时，设置合理的过期时间

如果过期时间不合理，要么Redis在不停的换入过期，要么内存很快撑爆服务器，对业务产生影响。

控制每个Redis实例的容量

Redis单实例的内存不要太大，通常建议时2-6GB。这样无论是RDB快照，还是主从集群的数据同步，速度都很快，不会阻塞正常的请求。

线上禁用命令

Redis是单线程处理请求，因此有些命令在线上使用有可能会长时间阻塞主线程。

KEYS，按照键值对的key进行内存的匹配，需要对Redis的全局哈希表进行扫描，严重阻塞Redis主线程，可以用SCAN命令代替，分批返回符合条件的键值对。使用SCAN后要记得主动删除游标
FLUSHALL，删除实例上所有的数据，如果数据量很大，严重阻塞Redis主线程。可以加上ASYNC选项，异步删除数据
FLUSHDB，删除当前数据库里的数据，同样可能阻塞Redis主线程。可以加上ASYNC选项，异步删除数据

慎用MONITOR命令

monitor命令可以监控Redis的运行状态，但是它会把所有的操作返回都输出到输出缓存区域。如果操作很多，输出缓存会很快溢出，这对Redis的性能造成影响。

慎用全量操作命令

对于集合类型来说，如果要获取全部数据，一般不建议使用全量操纵指令，比如HGETALL，SMEMBERS。它们会对数据结构做全量扫描，集合类型数据较多的话，会阻塞Redis主线程。建议如下：

可以使用SSCAN，HSCAN分批返回集合的数据，减少阻塞
可以化整为零，将一个大的集合拆成多个小集合
如果存储的是多个业务的多个属性，而每次查询的时候也要返回这些属性，那么可以用String类型，将这些属性序列化后存储，使用时直接返回String即可。

常见问题

雪崩

当大量缓存数据在同一时刻过期（即缓存数据失效）或者Redis故障宕机时，此时如果有大量的请求访问Redis缓存数据则会导致大量请求会直接访问数据库（即直接压入数据库），导致数据库压力剧增，严重的情况会导致数据库直接宕机，致使整个系统崩溃，这就是缓存雪崩。出现缓存雪崩主要是因为：

Redis中大量缓存数据同一时间过期
Redis故障宕机

解决方案：

过期时间设置随机值。这个方法最常用，数据的过期时间分散开来，就不会同时过期了
加互斥锁，然而在高并发的情况下，互斥锁会降低系统的吞吐能力。
双key策略，主key设置过期时间，副key不设置过期时间，两个key保存的值value是相同的，相当于副key是缓存数据的副本，当主key过期时可以直接返回副key的value（即缓存数据），而在主key更新时同时要更新主key和副key的缓存数据value。
针对Redis宕机，可以暂停对Redis的访问，直接返回错误；或者搭建高可用Redis集群，主节点宕机后可以自动切换节点。

穿透

用户访问的数据压根不存在Redis缓存中，也不存在数据库中，导致用户发送请求访问缓存时，缓存失效，便直接访问数据库也没有拿到数据，这样的话当有大量这样的请求打入时，数据库的压力会剧增，同样可能会导致数据库崩溃从而导致系统崩溃，这就是缓存穿透。

一般导致缓存穿透的情况有两种：

业务误操作（数据意外丢失）
黑客恶意攻击（故意访问一些不存在的数据）

解决方案：

设置缓存空值或者默认值，这种方案比较常用，查询不到数据的时候，可以在缓存里先放一个空值或者默认值，这样后续请求就会直接通过缓存返回了
非法请求的限制，入参前就校验是否合理，对非法请求进行拦截
设置可以访问的白名单。Redis的bitmaps类型可以定义一个可以访问的名单，如果访问的id不在bitmaps里，则不进行访问。
使用布隆过滤器，当数据写入数据库的时候，则更新布隆过滤器，当访问缓存数据不存在的时候，可以通过布隆过滤器尝试分析。布隆过滤器有一定的误判，查到数据库存在的数据有可能有一部分并不是真正存在的，但是检查不到的一定不在数据库。

击穿

大量用户请求同一个数据（即热点数据被频繁访问），刚好缓存中的热点数据过期，此时就会导致大量直接访问数据库，这样数据库很容易被高并发搞崩溃，击穿顾名思义针对一点不断打击，这就是缓存击穿。

解决方案：

加互斥锁，但是显然这种方式会导致吞吐能力下降
热点数据不设置过期时间，或者设计热点数据更新缓存，延长过期时间

缓存污染

缓存污染指的是缓存中一些只会被访问一次或者几次的的数据，被访问完后，再也不会被访问到，但这部分数据依然留存在缓存中，消耗缓存空间。缓存污染会随着数据的持续增加而逐渐显露，随着服务的不断运行，缓存中会存在大量的永远不会再次被访问的数据。缓存空间是有限的，如果缓存空间满了，再往缓存里写数据时就会有额外开销，影响Redis性能。

解决方案：

可以通过调整最大缓存值来避免内存太小影响性能，又要避免设置太大，影响同步。可以设置缓存容量为总数据量的15%-30%。

一致性问题

Redis作为缓存时读取数据时遇到的缓存失效后，在并发更新操作下，可以使用双写模式（即同时更新数据库和缓存），那么是先更新缓存，再更新数据库还是先更新数据库，再更新缓存呢？

先更新缓存，再更新数据库，线程1和线程2并发的进行更新数据操作，由于线程1在执行过程中存在卡顿情况，导致线程2执行完操作，才到线程1执行后面的操作。通过上图可以看到执行到最后的过程得到的结果是数据库中的数据是数据1，缓存中的数据是数据2。出现了缓存和数据库不一致的问题。
先更新数据库，再更新缓存，线程1和线程2并发的进行更新数据操作，同样由于线程1在执行过程中存在卡顿情况，导致线程2执行完操作，才到线程1执行后面的操作。过上图可以看到执行到最后的过程得到的结果是数据库中的数据是数据2，缓存中的数据是数据1。出现了缓存和数据库不一致的问题。
考虑删除缓存和更新数据库有失败的情况下, 情况会更复杂。

解决方法：

如果不要求数据具备实时性，能有一定的延迟的话，只需要在缓存中加上过期时间，这样数据最终总会一致。
如果对数据的一致性要求很高的话，则在更新缓存前加上分布式锁，保证同一时刻只允许一个线程进行操作，这样会避免了并发导致的问题，但是吞吐能力大大降低。
写入数据库如果失败的话，整个流程是肯定失败的，所有操作都应该回退。所以先写缓存的情况会更复杂。
写入数据库成功，但是删除/更新缓存失败，则应设置一定次数的重试，尝试更新缓存。如果重试次数超出，只能依赖缓存超期
先更新数据库再删除缓存的情况下，还可以利用binlog同步的机制，将数据更新到Redis里，可靠性更高

HotKey问题

在较短的时间内，海量请求访问一个Key，这样的Key就被称为HotKey。海量请求在较短的时间内，访问一个Key，势必会导致被访问的Redis服务器压力剧增，可能会将Redis服务器击垮，从而影响线上业务；HotKey过期的一瞬间，海量请求在较短的时间内，访问这个Key，因为Key过期了，这些请求会走到数据库，可能会将数据库击垮，从而影响线上业务。

治理Hotkey，需要解决从发现到通知Hotkey的产生，再到治理的过程。

如何发现Hotkey又可以拆解为两个子问题：如何知道每个Key的使用情况，以及如何统计。想要知道每个key的使用情况，可以在Redis客户端做埋点，也可以统一做一个Redis的代理，在代理层做埋点。前者管理不太方便，后者引入了新的故障点，需要综合取舍。统计的方式也有两种，一种是实时上报，业务系统的压力较小，但是上报数据很多；或者准实时上报，几类一定量或时间再上报，对业务自己有一定的内存压力。

发现Hotkey以后，由发现Hotkey的角色，通过MQ/RPC等方案触及客户端，告诉客户端Hotkey是什么，从而使得客户端可以处理Hotkey。

当客户端收到Hotkey以后，可以采用如下方式：

本地短时缓存Hotkey的数据，避免压力全部集中在Redis
将此Hotkey多分片存储到多个Redis实例，分散Hotkey的压力

此外，如果Redis采用主从+哨兵集群，则如果master节点挂了，就会自动切换一个slave为master，继续提供服务。这样也可以提高Redis的可用性。

事务里分布式锁失效

使用Redis做分布式锁还会遇到一种情况，就是在Transactional注解里使用分布式锁。可能代码会如下：

@Transactional  
public void updateDB(int lockKey) {  
  boolean lockFlag = redisLock.lock(lockKey);  
  if (!lockFlag) {  
    throw new RuntimeException(“请稍后再试”);  
  }  
   doBusiness //业务逻辑处理  
   redisLock.unlock(lockKey);  
}

它的问题是事务是函数返回后才执行的，但是此前分布式锁已经释放了，另一个线程完全可以做出不同的业务逻辑，导致最后事务无法提交，分布式锁等于失效了。有时候这个问题隐藏得会很深，必须得留意。

为什么是Redisson而不是自己写分布式锁

说到Redis用作存储分布式锁，有时候我们会看到有人这么写：

if（jedis.setnx(lock_key,lock_value) == 1）{ //加锁
	jedis.expire(lock_key，timeout）; //设置过期时间 
	doBusiness //业务逻辑处理 
}

这里的问题是，setnx和expire不是原子的。如果这个时候网断了，服务器挂了，都可能造成一个永久的锁。

还有人可能会这么写

if(jedis.set(lockKey, requestId, "NX", "PX", expireTime)==1){ //加锁  
   doBusiness //业务逻辑处理  
   return true; //加锁成功，处理完业务逻辑返回  
}  
return false; //加锁失败

return前没有释放锁，那么下次加锁只能等待expireTime超期了。

还有一种写法，使用getSet写的：

long expireTime = System.currentTimeMillis() + timeout; //系统时间+设置的超时时间  
String expireTimeStr = String.valueOf(expireTime); //转化为String字符串  
//锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）  
...//加锁失败,因为锁已存在
// 如果锁已经存在，获取锁的过期时间  
String oldExpireTimreStr = jedis.get(lock_key);  
...//存在一个旧的锁，但是锁的超时时间已经过了
String oldValueStr = jedis.getSet(lock_key, expireTimeStr);  
if (oldValueStr != null && oldValueStr.equals(oldExpireTimreStr)) {  
	//考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁  
	return true;  
}

这段代码的问题是，如果getSet有多个终端同时请求，那么有可能最后加锁成功的线程的超时时间，跟jedis里的value并不一致。

还有一些问题跟释放锁有关系。比如：

1
2
3

 if (requestId.equals(jedis.get(lockKey))) { //判断一下是不是自己的requestId  
      unlock(lockKey);//释放锁  
    }

有可能判断的时候锁是自己的，但是立刻过期了，然后被其它线程抢到了锁。那么最后unlock的时候，其实是解除了其它的锁。

还有锁超时释放了，但是业务没跑完，此时另一个线程会与当前业务形成竞争。这个最好是开启一个守护线程，业务没跑完的时候，就定期对锁做一些延长操作，可以避免提前释放。

就是由于有这么多问题，所以最好的办法，就是使用Redission。下边就是Redission的加锁方案：

此外，它还有WatchDog，每10秒监控一次锁的状态，如果业务没有释放，则自动续期30秒，避免业务没完成时锁被释放导致业务问题。

释放锁的时候，它会注意锁的可重入性，如果全部的锁都释放了，就会删除锁，然后广播锁的删除事件，再取消WatchDog对锁的自动续期。通常来说分布式锁都应当采用Redisson来维护。

解决linux无法启动tigervnc服务器的问题

Wed, 29 Dec 2021 00:00:00 +0000

使用Manjaro i3 作为在家里写代码的系统已经好几年了，公司的Mac老旧不堪，速度又慢，新的Mac又太贵，不禁想把公司的也换成DIY的机器，安装Manjaro写代码。

这个过程无需赘述，也安装了tigervnc做vnc服务器，从公司回到家里也能正常远程。既然是自己用的机器，看到有升级干嘛不升，于是升级了一下系统的内核，顺手点了重启。结果当我ssh上去，开启vnc server的时候，却提示【Invalid MIT-MAGIC-COOKIE-1 keyx0vncserver: unable to open display “:0”】。

奇怪了，只要我在公司用过电脑，都是可以正常远程的，而重启的时候，公司的显示器是关闭的。莫非是我显示器的电源没开，所以它不认display :0？一番探索后发现，并非如此。Xorg也开着，但是这个:0 不管是普通用户还是root，都无法开启vnc服务器。再一番探索后才发现，原来tigervnc必须要用户图形登录后才能提供vnc服务，原因应该是xauth了。

所以最简单的办法就是调整一下思路，让电脑开机后自动登录，但是既然是在公司，登录后肯定不能让别人用啊，所以登录后再自动锁屏就行了。对于Manjaro和i3来说，这种调整非常简单。

首先是自动登录，编辑/etc/lightdm/lightdm.conf文件，将autologin-user=用户名的注释打开，就能让系统开机自动登录了。

然后是自动锁屏，manjaro的锁屏程序是blurlock，我的桌面管理器是i3，那么编辑~/.i3/config，增加一行exec –no-startup-id blurlock，就轻松搞定了。

最后reboot一下，果然就好使了。

走近DDD

Sun, 26 Sep 2021 00:00:00 +0000

《领域驱动设计精粹》这本书是 DDD 的发明者Evans在提出DDD多年后写的一本小册子，是为了降低DDD上手难度而写的一本小册子，它很棒地阐述了DDD的来龙去脉，而没有落入与之无关的细节中——入门的时候就是应该高屋建瓴，不是吗？

为什么需要DDD？

没有实施DDD的情况下，我们经常会遇到什么问题？

开发人员热衷于技术而不是深入了解业务。这是技术人员的职责使然，一个不高级的开发，通常他的业务经验不重要；一个高级的开发，通常因为竞业，也无法继续干类似的业务。所以开发人员对业务天然的没有足够的兴趣。但是开发过程中，对业务不够熟悉，很容易发现开发做了半天得到的，并不是用户和产品想要的；或者下次再有需求的时候，技术上的改动特别大，成本很高。
业务协作不畅，一个需求提到好几个团队都能做，但是开发过程你推我我推你，需求一拖再拖，有时候项目中期还得找其他团队求资源。
对项目工时的估计占用了不少精力，还不准确。估时这件事能成为管理层和开发人员之间的拉锯战。
服务之间紧耦合，牵一发而动全身，一个非核心的业务抖一抖，客户都说没法用。

那么 DDD 怎么解决这些问题？

找到边界：让设计系统的人知道一个业务的边界在哪里。只有知道边界在哪里，才能在需求到来的时候，轻易地找到相关团队，各个业务之间也才能真正解耦，降低非核心功能对核心功能的影响。
知识获取：保证设计系统的人能够低成本地了解业务，让大家在怎么做，怎么验收方面达成一致。在此基础上，还可以免费得到一款评估时间的工具，项目的交付就更有把握。

但是在此我要多说一下，我们现实实践中已经有一部分领域概念的影子了——谁能说他不知道自己的组织是干啥的？或者说哪个组织没有业务重心呢？可是为什么大家没有获得上边说的这诸多好处呢？那是因为DDD实践过程中巧妙地将设计模型落地成为开发的模型，让需求方和实施方说一种语言，才能真正跨越了需求和实现之间的鸿沟。所以实践DDD，绝不是只有开发写写代码就行，而是要跟产品，设计以及领域专家一起完成设计，才能得到DDD的好处。

DDD是什么呢?

我们先看几个*DD：

TDD 驱动测试开发
BDD 行为驱动开发
ADD 不是单词Add，而是 API 驱动开发
DDD 领域驱动设计

前面几个概念落脚点都是开发，而DDD，是设计。

它有三个关键词：领域，驱动，设计。领域，是要探索业务的边界；驱动,表示前者是后者的决定性因素；设计，包括产品设计，UIUE设计，软件设计。它不仅仅是开发架构的方案，而是完整的解决方案实施思路。正是因为它是完整的方案，才能让领域专家，产品和研发真正在同一个角度去思考和沟通，避免推诿扯皮，含糊不清。

那么怎么做DDD呢?

实施DDD一般有两步，并且需要开发，产品和领域专家的通力合作。为了实施速度有所保障，还有一些项目加速和项目管理工具：

战略设计
战术设计

战略设计

战略设计可以说是搭建了业务思想上的框架。这个阶段要做这么几件事：

使用限界上下文分离领域模型
在限界上下文发展通用语言
使用子域处理遗留系统
使用上下文映射来集成多个限界上下文

限界上下文分离领域模型

限界上下文这个名字乍一看，每个字我都认识，但是这个词是啥意思？原文说它是语义和语境上的边界，我的理解是，它是在描述组织交付出来，面向客户的交付边界。如果是在SaaS场景，一个限界上下文应该是一个独立交付的软件；在PaaS场景，它应该说的是一个独立售卖的模块。它的含义是找到一个边界，要把这个边界以外的当成是无法改变的客观环境，不要幻想这个边界以外的人会配合你一起完成交付。那这一步设计就很好理解了，就是找到你业务对外承诺的边界，你要发展的业务在这个边界内，而不在此之外。如果你是对内交付的系统，那么你对其他同事交付的业务边界，就是你的业务限界上下文。

一个组织里，最核心的限界上下文被称为核心域。通常除了它，还有通用子域和支撑子域。通用子域是很成熟的业务，通常可以外包或者购买现成的解决方案，比如搜索子域可以通过ES来支持；支撑子域通常没有现成产品，但是它没有核心域重要，因此也可以一定程度的外包，避免在核心域之外浪费资源，比如大多数公司的数据库中间件是在开源产品上做了一些定制开发和维护。

限界上下文这个概念的目的是为了在业务扩展的时候，防止向领域内注入概念，导致业务变得没有边界，纠缠在一起。

在做这一步的时候，DDD要求以领域专家意见为准，正所谓领域驱动嘛。当实施了DDD方法以后，不论是领域专家还是开发，都应该拒绝向领域注入与业务无关的概念，比如存储方式等。这与我们日常工作从如何存储开始构建业务系统是完全不同的。只有把这些技术概念放到业务之外，我们的业务核心往往才能足够集中，易于迁移，而且不论采用什么东西存储，用什么东西展示，它的逻辑都可以不变。

这个过程中我们通常可以得到这样一个模型：

限界上下文发展通用语言

当我们有了业务的限界上下文以后，就需要在这个限界上下文中发展一种语言用于表达软件模型，这个语言就叫做这个限界上下文里的通用语言。它可以是任何计算机语言、人类语言或者图形，只要能让团队内的每个人都能看懂。

通用语言不止是名词，它应该使用一系列具体的模型场景来描述领域模型。它描述了各种业务组件（不是技术组件）做什么，而不是用例或者用户故事。

比如微信朋友圈点赞这个场景，通用语言可能是：用户可以通过点赞，使得某个朋友圈的Feed发出人收到被点赞的通知，达到互动的目的。

但是到这一步，我们怎么能验证领域模型能与领域专家的心智保持一致呢？那就是为这个模型写验收测试，并交由领域专家评估。一种做法是验收测试采用given-when-then语法（中文可以用假如-当-那么），便于阅读理解。验收测试也可以用脑图，文字来描述，甚至DDD不反对采用单元测试框架写验收测试，只要领域专家能够阅读并理解写出的验收测试。

这一步做完后我们的模型图形其实没什么变化，但是现在，开发能够更充分的了解业务了。

使用子域处理遗留系统

我们代码不是在真空里运行，它们免不了会跟一些遗留系统打交道，这些遗留系统的边界并不清晰。因此我们会将遗留系统放到一个子域里，把它们的问题放到我们的设计之外。这一步做完后我们的图案与之前没有本质上的区别，无非是多了一点子域。

使用上下文映射来集成多个限界上下文

上下文映射是两个限界上下文之间的连线，表示了这两个概念之间的关系，也表示这这两个概念的通用语言的翻译。通常来说，不同的限界上下文是不同的团队在维护，那么此时它也代表着两个团队之间合作的关系。

我们常见的映射关系是RPC接口。然而在领域设计里，限界上下文之间使用RPC是有风险的方案，因为会承受网络风险，还意味着两个限界上下文之间存在紧耦合。如果系统A阻塞请求系统B，B又请求C，就很容易导致集成火车事故：火车里某一节车厢有问题就会变成整列火车的问题。

最好的限界上下文映射关系采用事件的订阅，但是这要求领域专家在设计的时候就考虑不同领域之间通知的延迟对于业务的影响，以及如何消除影响。如果不采用DDD的方式，领域专家通常无法意识到领域之间的同步成本，技术人员也很容易一头撞进集成火车里。这就是我说的：DDD的目标是找到边界和促进学习知识，不仅仅是开发学习业务，领域专家也是在学习系统的边界与设计。

战术设计

在战术设计阶段包括如下设计：

把一些实体和值对象放一起，称为聚合。
利用领域事件通知相关系统。

聚合怎么设计

一个限界上下文里通常有多个聚合，聚合逻辑上是相对独立的。怎么理解聚合的概念呢？在DDD实践中，聚合是事务的边界；聚合之间并不保证事务，只能用最终一致性。任何需要事务保护的逻辑都应该在一个聚合内。在限界上下文里，将其他聚合能力整合在一起对外提供能力的聚合，被称为聚合根；其他聚合也被称为实体。

此外，一个限界上下文里还有值对象，它也代表了某种相对独立的概念。怎么区分实体和值对象呢？这取决于业务。如果一个名词，具有多种动词去操作它，那么它应该是一个实体；如果一个名词，在系统里只是被传递而没有业务逻辑，那么它就是值对象。

由于聚合是事务的边界，那么每个聚合在设计阶段，最重要的是找到业务的不变性，也就是说，在事务提交前后，数据的约束条件。比如说，你在知乎对一条回答点赞，那么这条回答的点赞数量必须立刻多1，那么点赞的动作和点赞的计数，就应当在一个聚合内。

领域专家必然希望任何事情都能在触发后立刻完成，所以在沟通的过程中要不断质疑，如果不实时地做一件事，会不会有问题。甚至可以用一个夸张到显然无法接受的时间长度来质疑，以促成领域专家对此认真思考。

在聚合被设计出来以后，我们的模型图看起来会是这样的：

领域事件怎么设计

我们说聚合之间要采用最终一致性，而通常的做法是采用领域事件实现最终一致性。领域事件的名称应该采用通用语言命名，才能符合领域专家的心智。完整的时间名词应该是名词和动词构成的，动词应该是过去时。领域事件的名字和属性应该能够完整描述这个事件的含义。

事件里通常至少包含业务动作和其业务参数，也可以增加更多的下游关注的事件信息，避免下游为了完成处理还需查询。

领域事件会持久保存在专门的数据表中，用来表示领域事件的因果关系。

有一种专门的存储方式是事件溯源，它不需要存储数据当前是什么，而是从历史事件中按顺序应用重建，得到当前的数据。这样写入时的成本只有校验后持久化，也没有增加和删除的能力。如果事件很多，性能问题很大，也可以加上缓存和快照，优化性能。这种方案通常会与CQRS方案一起做。

进度加速和项目管理工具

在这本小册子里,Evans提出了两个工具，分别用于加速设计阶段和评估工时。

事件风暴

事件风暴是快速的设计技术，让领域专家和开发人员都可以参与学习，目的是在有限的时间里尽可能多地完成设计，也就是加速设计阶段。

事件风暴要先做如下准备：

邀请领域专家和开发人员
每个成员都应该以开放的心态参与讨论，不必追求正确和速度。
各种颜色便利贴，正方形的。一般一个便利贴只会写几个词。
每个人都有黑色的马克笔。
最好有一面至少10米长的墙并且铺上白纸。最好建模的几天时间内保持每次讨论的结果一直保留并供下次讨论使用。

事件风暴的基本步骤：

在便利贴上写领域事件，梳理出业务流程，一般是橘色。
1. 创建领域事件强调我们首要关注的是业务流程，而不是数据和结构
2. 把每个领域事件写在一张便利贴上，应该是动词的过去式。
3. 把写好的便利贴按照时间顺序放到建模平面上，从左往右逐步发生。
4. 并行发生的领域可以上下排列，不明白时机的事件可以单放在某个单独的位置。
5. 如果发现了问题点，可以用红色的便利贴上，并用一段文字解释是什么问题。
6. 领域事件最终会触发一个执行的流程，每个流程都应该命名并记录在浅紫色的便利贴。需要从领域事件画个箭头指向这个流程。支队核心域中非常重要的细粒度事件进行建模。
创建导致领域事件发生的命令，命令应该是指令式的。
1. 创建领域事件的便利贴是浅蓝色的。
2. 触发事件的便利贴放在触发的事件左边，会有很多成对出现的命令和事件。但是也有不是命令触发的事件，比如时间触发的事件。
3. 如果存在一个执行动作的特定角色，那么可以在命令左下角使用亮黄色的便利贴记录角色名称。
4. 命令也可以触发流程。
5. 在命令和事件之间画出线条
6. 按照时间顺序，将命令和事件的关系处理好
7. 一个命令可以带来多个事件
把命令和领域事件通过实体、聚合联系起来。由于建模没完，因此没有真正的实体和聚合，而是领域专家思想里的业务概念和概念群。用淡黄色的便利贴来表示聚合，其左下角是命令，右下角是事件。聚合的名字应该是名词。
在建模平面上画出边界和事件流动的箭头。
识别用户执行操作所需的各种视图，以及客户不同用户的关键角色。

4和5是事件风暴的关键。

时间评估工具

时间评估工具是如下的一个经验表格：

领域内的组件类型	简单	适中	复杂
领域事件	0.1	0.2	0.3
命令	0.1	0.2	0.3
聚合	1	2	3
…

作者Evans在原始表格里使用的单位是人时，然而根据我的经验，这个地方用人天还差不多……

这个表格的好处是系统里关于业务的部分都很明确了，虽然时间还是经验得出的，但是实际上已经相对精细了，而且在领域内的部分，估时会更准确一些，而且它的复杂度与业务方的预估不会差太多。

常见的DDD误区：

DDD一定要用微服务？不，其实多个域在同一个进程也没问题，只要满足一个聚合在一个事务内保护就没有问题。
DDD的架构是稳定的？这么问的人一定没有理解什么叫做领域驱动。当领域发生演化的时候，系统的改变肯定不会小。比如电商系统里收货地址，可能一开始只是没有业务意义的值对象，但是后续有了管理，比如家庭，公司，然后反过来绘制画像，精准推荐……地址有了管理系统，那就不再是值对象了。但是DDD能保证在每期迭代中，需要做的工作都是最贴合当前需求的，并且当下一迭代到来的时候，做的改造工作量也是各方可以理解的。与之相反的所谓提前规划，通常会演化为把之后若干迭代的部分放到当前迭代，而且当未来没有按照预定的方式改变时，这些工作可能还是无效的。

后记

我只是针对Evans的入门小册子做了读书笔记，它不涉及具体的代码设计部分。其实DDD的关键在于让业务，产品都参与系统设计，因此怎么写代码，其实还在其次。有兴趣看怎么在代码里实践DDD，在此推荐使用DDD指导业务设计的一点思考这篇文章。

欢迎大家在评论区分享和讨论关于DDD的知识。

提升个人影响力的简单原则

Thu, 09 Sep 2021 00:00:00 +0000

今天看到一篇讨论个人影响力的文章，感觉讲得不错，分享给大家。原文地址

个人成长和投资一样，要学会利用杠杆的力量，影响力就是一项可以帮助自己更高效达成目标的杠杆。利用一些技巧，提升自己在团队中的影响力，从而提升自己的工作效率，创造更多的价值。原文：Low Hanging Fruits of Having a Bigger Impact[1]

有一项能力对我们的职业发展非常重要，那就是创造价值的能力。接下来让我们聊一聊在我们的每项工作中所创造的价值，这些价值就是我们的影响力。我们可以很容易的发现影响力和效率之间的关系：我们所拥有的影响力越大，我们的工作效率就越高。

拥有更大影响力的首要原则是专注于高杠杆活动（high-leverage activities）。还记得帕累托原理（Pareto Principle）[2]吗？这正是我们所需要利用的。

作为软件开发人员，可以做些什么来轻松的增加我们的影响力？下面是几个例子：

指导公司的新员工。众所周知，新员工需要3到6个月的时间才能达到正常的生产力水平。在某些情况下，员工可能需要2年时间才能达到最佳绩效[3]。如果你能在新员工入职的第一个月，每天花1个小时（总共大约20个小时），那么你将花费一年工作时间（总共大约2000个小时）的1%来提升同事的表现。这将对他们的绩效提升有很大的帮助，而你的时间投资也因此获得了巨大的回报。
参与面试过程。改进流程，为公司引进候选人，进行面试，这些都是对我们的团队和产品的直接投资。从长远来看，聘请优秀的人才将会带来巨大的回报。
不要再重复发明轮子，尽量利用别人的专业知识。把时间投入到创造独特的价值上，而不是重新创造已有的东西。开源模块和组件、第三方软件、同事的经验、甚至外包和自由职业服务都是更快获得现有解决方案的可行选择。
自动化和优化流程。人们常说，手工重复工作是每个程序员最大的罪过。如果一项工作能让机器为我们做，我们就不应该自己去做。从长远来看，一个简单的自动化脚本可以节省几个小时的团队工作。如果我们优化了构建系统，每天节省了30分钟的等待时间，那么我们每年将为单个开发人员创造14天的空闲时间。在一个6人的小团队中，它的结果是3人月的额外时间。
持续学习，不断完善自我。这一点尤其需要强调：我们应该在工作中专门花时间学习和提高自己。没有什么比投资于自己的能力和现有的机会能给你带来更大的影响和提供更大的杠杆了。

可以看到，上面列举的几个方向（和原则）主要是通过关注我们周围其他人来提升我们的效率。这也是为什么一些软件开发人员更喜欢过渡到管理角色的主要原因之一——这样可以更快的获取更多的杠杆。

然而，管理并不是唯一的可能性。更重要的，如果你想打破玻璃天花板，你需要专注于增加影响力。

接下来，记住第二条重要原则：你的努力应该是可见的。例如，如果你的老板不知道你指导了同事、自动化了一些日常任务，你就不会很快得到晋升。你需要强调获得的小的进展和成就，并将所创造的价值传达出去。

如你所见，在某种程度上，人际关系和沟通对我们的成长至关重要。不要忽视这些方面，把时间花在掌握一些软技能上。

Reference: [1] https://www.patreon.com/posts/low-hanging-of-18230210

[2] https://en.wikipedia.org/wiki/Pareto_principle

[3] http://recruitshop.com.au/long-take-employee-fully-productive/

走进Lombok

Sat, 31 Jul 2021 00:00:00 +0000

Lombok 是什么

Lombok 是为了解决 Java 语法啰嗦而产生的工具，能够自动为编辑器和编译器产生代码，避免一部分体力劳动。比如我有一个Pojo，本来它是这个样子的：

public class Test {  
    public static void main(String[] args) {  
        final Pojo build = new Pojo();  
                build.setA("a");  
        build.setB(true);  
        build.setNames(Arrays.asList("name1","name2"));  
        System.out.println(build);  
    }  
  
    public static class Pojo {  
        String a;  
        Boolean b;  
        List<String> names;  
  
        public String getA() {  
            return a;  
        }  
  
        public void setA(final String a) {  
            this.a = a;  
        }  
  
        public Boolean getB() {  
            return b;  
        }  
  
        public void setB(final Boolean b) {  
            this.b = b;  
        }  
  
        public List<String> getNames() {  
            return names;  
        }  
  
        public void setNames(final List<String> names) {  
            this.names = names;  
        }  
        
        @Override  
        public String toString() {  
            return "Test.Pojo{" +  
                "a='" + a + '\'' +  
                ", b=" + b +  
                ", names=" + names +  
                '}';  
        }
    }  
}

但是我用了Lombok以后，它是这个样子的：

public class Test {  
    public static void main(String[] args) {  
        final Pojo build = Pojo.builder()  
                .a("a")  
                .b(true)  
                .name("name1")  
                .name("name2")  
                .build();  
        System.out.println(build);  
    }  
  
    @Data  
    @Builder
    @NoArgsConstructor
    static class Pojo {  
        String a;  
        Boolean b;  
        @Singular  
        List<String> names;  
    }  
}

输出是Test.Pojo(a=a, b=true, names=[name1, name2])。

是不是可读性高了不少？这就是Lombok的效果了。

Lombok 怎么用

Lombok 是通过注解来完成其功能的。我把Lombok的注释分为如下几类：

Pojo代码生成类
语义增强类
变量的注入和局部变量增强类

Pojo代码生成类

这一类注解主要用于Pojo里，可以避免体力劳动。

@Getter @Setter

最常用的，莫过于Getter和Setter，正如名字所示，它们可以为类和字段生成getter和setter。默认可以通过AccessLevel控制生成的函数的公开程度。示例如下：

public class Test {  
    public static void main(String[] args) {  
        final Pojo pojo = new Pojo();  
        pojo.setA("a");  
        pojo.setB(true);  
        pojo.setNames(Arrays.asList("name1","name2"));  
        System.out.println(pojo);  
    }  
  
    @Setter  
    @Getter 
    public static class Pojo {  
        String a;  
        Boolean b;  
        List<String> names;  
    }  
}

@NoArgsConstructor @AllArgsConstructor @RequiredArgsConstructor

这几个也很常用，分别是无参构造函数，所有参数的构造函数，以及必填参数的构造函数。无参构造函数和所有参数的构造函数都很好理解，最后这个必填参数怎么去找呢？是找到打了@NonNull注解，或者是final的字段，会当成是必填字段。

这三个构造函数的注解还有一个能力，可以通过staticName，来生成一个静态的工厂，此工厂可以根据参数来使用相应的构造函数。这个能力通常是用来接受一些类型参数来构造一个具有某种类型信息的Pojo。示例如下：

public class Test {  
    public static void main(String[] args) {  
        final Pojo pojo = new Pojo(Arrays.asList("name1","name2"));  
        pojo.setA("a");  
        pojo.setB(true);  
//        pojo.setNames(Arrays.asList("name1","name2")); 不能再set  
//        pojo.getNames().add("name3"); java.lang.UnsupportedOperationException  
        System.out.println(pojo);  
    }  
  
    @Data  
    @AllArgsConstructor 
    @RequiredArgsConstructor 
    public static class Pojo {  
        String a;  
        Boolean b;  
        final List<String> names;  
    }  
}

@ToString @EqualsAndHashCode

这两个注解能够为被注解的类增加toString，equals和hashCode函数。如果有继承关系，一般还要把callSupper=true打开，可以将父类的字段囊括到计算中。如果对象里有一些字段是不用参与相等判断的，可以用exclude来排除一些字段。示例如下：

public class Test {  
    public static void main(String[] args) {  
        final Pojo pojo = new Pojo();  
        pojo.setA("a");  
        pojo.setB(true);  
        pojo.setNames(Arrays.asList("name1","name2"));  
        System.out.println(pojo);  
    }  
  
    @ToString  
    @EqualsAndHashCode
    @Setter 
    @Getter
    public static class Pojo {  
        String a;  
        Boolean b;  
        List<String> names;  
    }  
}

@Data @Value

@Data其实是@Getter，@Setter，@RequiredArgConstructor，@ToString，@EqualsAndHashCode的集合，而@Value则是@Getter，@FieldDefault，@AllArgsConstructor，@ToString，@EqualsAndHashCode和@Data的集合。基本上打了这两个注解的，一定是当成了一个Pojo来使用。它们的区别是什么呢？@Data的对象没有什么特别的，但是@Value的对象，是当作不可变对象来使用的，一旦构造结束，也就不能变更了。但是要注意的是，上述@Data不包括@NoArgsConstrutor，当你的Pojo在经历反序列化过程的时候有可能会报错，需要人为补充@NoArgsConstructor。

@Builder @Singular

@Builder 可以为指定的Pojo生成一个Builder，通过Builder去实现一个类的Builder模式，解决构造的参数复杂异变带来的问题，如果说这个Builder还有哪里难用，那就是它默认对数组的设置需要填写一个完整的数组。众所周知，Java构造一个数组的语法是相当的啰嗦。而@Singular则可以为Builder中的数组元素提供单个元素的增加方法，build一个复杂对象更加容易了。开篇的示例就是这两个注解的使用方法。

@With

通过在字段上的注解With，我们可以通过With，将原有对象复制一份，所有字段都一样，除了with所指定的字段是新的。

语义增强类

@CustomLog

这是为了给被打注解的类注入一个logger。对于lombok.log.custom.declaration=my.cool.Logger my.cool.LoggerFactory.getLogger(NAME)的配置来说，会对目标类

1
2
3

@CustomLog  
public class LogExample {  
}

生成如下代码

`1`	`private static final my.cool.Logger log = my.cool.LoggerFactory.getLogger(LogExample.class.getName());`

但是现在通常使用已经封装好的Logger，所以，它有@Log，@CommonsLog，@Log4j，@Log4j2，@Slf4j，@XSlf4j，@JBossLog，@Flogger一系列注解，可以直接使用项目里已有的logger。

@SneakyThrows

Java面试题里经常问，怎么才能偷偷在一个没有声明Throws的函数上抛出一个checkedException？这个大家知道了原理，但是用的时候，大可不必自己造轮子，因为Lombok已经把轮子造好了，原理是利用了泛型抹除。但是我觉得这个注解应该慎用，因为用了这个注解，就把函数里的异常抛出情况掩盖了。比如

public class Test {  
    public static void main(String[] args) {  
        final Pojo pojo = new Pojo();  
        pojo.setA("a");  
        pojo.setB(true);  
        pojo.setNames(Arrays.asList("name1","name2"));  
        pojo.test();  
    }  
  
    @Data  
    public static class Pojo {  
        String a;  
        Boolean b;  
        List<String> names;  
          
        @SneakyThrows  
        public void test(){  
            throw new OperationNotSupportedException();  
        }  
    }  
}

会输出Exception in thread "main" javax.naming.OperationNotSupportedException

@Synchronized

这个注释名字大家太熟悉了，我们先看个例子：

public class Test {  
    @SneakyThrows  
    public static void main(String[] args) {  
        final Pojo pojo = new Pojo();  
        pojo.setA("a");  
        pojo.setB(true);  
        pojo.setNames(Arrays.asList("name1","name2"));  
        int concurrency = 10;  
        final ExecutorService executorService = Executors.newFixedThreadPool(concurrency);  
        final CountDownLatch countDownLatch = new CountDownLatch(concurrency);  
        final List<Callable<Object>> collect = IntStream.range(0,concurrency).mapToObj(i -> new Callable<Object>() {  
            @Override  
            public Object call() throws Exception {  
                pojo.counterAdd(i);  
                countDownLatch.countDown();  
                return null;  
            }  
        }).collect(Collectors.toList());  
        final List<Future<Object>> futures = executorService.invokeAll(collect);  
        countDownLatch.await();  
        executorService.shutdown();  
        System.out.println(pojo.getCounter());  
    }  
  
    @Data  
    public static class Pojo {  
        String a;  
        Boolean b;  
        List<String> names;  
        volatile int counter = 0;  
  
        @Synchronized  
        public void counterAdd(final int i){  
            counter += i;  
        }  
    }  
}

由于counter的add是有并发的情况的，通过注解，保证调用时不会导致加法失效。

乍一看这个注释跟我直接在函数上加修饰符synchronized，难道不一样吗？嘿，别说，虽然例子里的效果一样，但是原理还就是不一样。在函数上加的修饰符，锁的是对象的实例；用Lombok的注解，加的锁是对象里生成的一个字段，默认名称lock，我们可以根据自己需要调整不同的名称，达到更细粒度的锁。而且这能防止this在对象外被别人拿去当锁了，会造成不可以意料的死锁。

变量的注入和局部变量增强类

@Cleanup

在try with语法之前，关闭closable通常都写得很罗嗦，尤其是有嵌套的时候——这种情况还挺常见。即便是现在有了try with语法，多层嵌套还是很难看。但是用了@Cleanup，那就简单多了。比如这个例子：

public class Test {  
    @SneakyThrows  
    public static void main(String[] args) {  
        @Cleanup final Pojo pojo1 = Pojo.builder().name("pojo1").build();  
        System.out.println(pojo1+ " created.");  
        @Cleanup final Pojo pojo2 = Pojo.builder().name("pojo2").build();  
        System.out.println(pojo2+ " created.");  
        System.out.println(pojo1);  
        System.out.println(pojo2);  
    }  
  
    @Data  
    @Builder 
    public static class Pojo implements Closeable {  
        String name;  
  
        @Override  
        public void close() throws IOException {  
            System.out.println(this + " closed.");  
        }  
    }  
}

最后输出是

Test.Pojo(name=pojo1) created.
Test.Pojo(name=pojo2) created.
Test.Pojo(name=pojo1)
Test.Pojo(name=pojo2)
Test.Pojo(name=pojo2) closed.
Test.Pojo(name=pojo1) closed.

我们看关闭时顺序与创建的顺序是反的，完全正确。

@val @var

在Java支持var 和 val之前，一个类的名字如果要尽可能准确，那长度就很难减少；但是Java语法要赋值一个变量，就得为这个变量指定类型，最终，一个赋值都能写一百多列，非常难看。用了这组注释，再也不用写超级长的类名了。正如大家常用的其它语言，val是不可变量，var是可变量。不过现在Java已经支持了val和var，这个注解就用不到了。

Lombok 的原理

说完了用法，我们肯定会好奇，它为什么引入了依赖，就能自动帮我们完成这么多复杂的工作？通常我们写注解，都会自己写一些注解解析工具来完成注解的的使用工作，而这种工具通常得明确定义出来，或者放到框架的某个生命周期才能生效。Lombok是怎么做到的呢？

原来Lombok使用了一个Java的特性：JSR 269，也就是Pluggable Annotation Processing API。这样在Java编译的时候，Lombok就会被Javac唤起，用来增强实现的效果。如果想了解其具体的实现方案，可以看lombok.javac.handlers包下的各种handler。

Lombok 的注意事项

构造函数的易变性

如果过度依赖Lombok提供的注解来生成构造函数的话，一定要留意对象变更时这几个构造函数的重叠问题。比如当对象里的字段都废弃掉的时候，无参构造函数和全参构造函数参数一致了，编译过程会报错；或者增减字段的时候，原先的全参构造函数被直接使用的地方编译就报错了，也得改代码。更不要说调整字段顺序的时候全参构造函数一定会失效。我认为最好使用builder进行构造，语义清晰，而且修改的时候不容易错。

默认构造函数的丢失问题 @AllArgsConstructor @Builder

如果一个Pojo，只打了@AllArgsConstructor或@Builder，那它会吃掉默认的无参构造函数，在一些序列化框架上会报错。所以这个通常都会把无参构造函数的注解打上去。

注解的继承问题

@Data默认是有@EqualsAndHashCode注解的，但是callSuper并没有打开，也就是说，两个打了@Data的子类，在做Equals等判断的时候，没有考虑父类的字段。这种情况还需要大家自己再打一下@EqualsAndHashCode注解，并且把callSuper打开。

Kotlin与Lombok的集成问题

Kotlin与Lombok不同，它有单独的Compiler，执行的时机早于Lombok的注解工具执行，这会导致如果想在Kotlin里调用Lombok的生成的代码，会找不到实现。这个问题可以通过Delombok来解决，Delombok会先将Lombok处理的代码编译到编译后的目录，保障Kotlin能访问到增强后的函数，避免编译失败。目前Kotlin项目组应该也注意到了这个问题，已经在开发Kotlin的lombok编译插件，其原理是生成stub，避免编译器失败。目前还在实验阶段，注解的支持有限，感兴趣的可以看https://kotlinlang.org/docs/lombok.html

附：阅读 Lombok项目

Lombok项目是开源的，托管在github上边，地址https://github.com/projectlombok/lombok

Lombok项目是通过ant管理的，并且ant执行的最低版本是Java11。项目下载后在根目录可以使用ant IDE方式为使用的ide生成项目文件，可以使用的是ant eclipse和ant intellij。由于项目组成员全部是eclipse，所以不保证intellij的脚本可以使用，而且，经过测试，它确实不能使用LoL。好在intellij可以使用导入项目的功能，在生成eclipse文档后，当成是eclipse项目导入即可。

由于是Ant项目，跟Maven项目的默认结构差异还是不小的。不过阅读其源代码，主要关注的是src目录下的core目录。我们日常使用的注解就在这个目录下。

目录下还有若干子目录，bytecode是它对字节码操作的一些工具，core是核心处理，javac是它对javac的支持。core\handlers目录下是各个注解的处理方式。

在Mac上打开Iterm或终端时重建tab

Mon, 19 Jul 2021 00:00:00 +0000

长期以来都不知道 Mac 上的 iTerm2 或者自带的 Terminal 程序怎么能在打开的时候恢复上一次关闭的标签，但是如果 Mac 四国重启，发现都是能打开上一次的标签的，说明有这个功能。

今天谷歌了一下，看到很多答案都是在系统设置里，一开始我还以为是答非所问，试了一下才发现所言非虚^_^。

答案就是在系统设置下的通用设置里，不要勾选「退出 App 时关闭窗口」。对于 iTerm，还需要在 General 设置页的 Startup 设置里选择 Use System Windows Restoration Setting。

这样下次打开的窗口的时候就能恢复上次关闭的窗口啦。

Java流水帐代码的重构与单元测试

Sun, 27 Jun 2021 00:00:00 +0000

背景

大多数软件开发者都是学过很多编程思想和知识的人,绝对不是不知道什么代码是好的,什么样的代码是糟糕的.

然而我们在工作的过程中,为了满足和解决各种现实问题,会在代码里产生引入各种妥协和交换.最后有一天,我们发现,bug产生于一大段肮脏的业务代码,就像这样:


public class Test {
    //输出业务计算的结果
    public static void main(String[] args) {
        final Biz.Argument argument = Biz.Argument.builder()
                .a("content a")
                .b(9)
                .c(false)
                .build();

        new Biz().getBizResult(
                argument
        );
    }

    //业务的实现类
    public static class Biz {

        //通常是注入的外部服务
        private volatile IntegerCalculator integerCalculator;

        {
            integerCalculator = new IntegerCalculator();
        }

        @AllArgsConstructor
        @Builder
        @NoArgsConstructor
        public static class Argument {
            String a;
            int b;
            boolean c;
        }

        //计算业务结果的过程
        public String getBizResult(Argument argument) {
            //一段校验逻辑
            if (argument.a == null || argument.b > 10 || argument.b < 0) {
                throw new RuntimeException("argument is not valid.");
            }

            String result = "not inited.";
            Throwable throwable = null;
            try {
                if (argument.c) {
                    result = argument.a;
                    return result;
                } else {
                    result = String.valueOf(integerCalculator.calculate(argument.b));
                    return result;
                }
            } catch (Throwable t) {
                throwable = t;
                throw t;
            } finally {
                // 通常是统计和上报
                if (throwable == null) {
                    System.out.printf("result is %s", result);
                } else {
                    System.out.printf("result is %s, throwable message is %s,", result, throwable.getMessage());
                }
            }
        }
    }

    //外部服务的实现,现实生活中实现通常是远端服务,这里写出来实现只是为了跑通测试
    //我们开发者只基于接口约束开发,对于其实现有没有bug不负责
    public static class IntegerCalculator {
        @NotNull
        public Integer calculate(@Nullable Integer integer) {
            if (integer == null) {
                return 0;
            }
            return integer * integer;
        }
    }
}

getBizResult 这一段代码里混合了三种逻辑,包括了校验,业务逻辑和统计上报. 代码初期可能并不复杂,但是后续类似的逻辑越加越多,维护成本会很快升高.我称之为流水账代码.

改造方案

怎么样才能更可靠的拆解上述函数,使之更容易维护呢?我总结了一套重构方法,能够安全又快速的达到上述目标。此方法依赖于Java8 引入的一个能力: 在接口上提供default函数,也就是说,低于Java8,你就无法使用这种方法了.它一共有五步:

将流水账函数的参数访问,变为函数内的局部变量
将函数内的局部变量转为context对象的public属性
将context的public转为private
将流水账内的每一个功能转为一个private函数
将上述private函数抽象到接口的default实现里

具体操作

第一步将流水账函数的参数访问,变为函数内的局部变量

改造的第一步是先将要治理的函数内对函数参数的访问,抽取为函数的局部变量.这一步并不是最终目标,它是为了将对函数入参的直接访问,改为对中间变量的间接访问,并且每一个参数都得是可以最大复用的对象.比如说你项目都是基于公司的同一套中间件,那么抽取后的函数变量可以是中间件提供的对象;如果不是,那最好参数是都是Java自带的类,改造后提供的函数才能最大的复用.改造后的getBizResult如下:

//计算业务结果的过程
        public String getBizResult(Argument argument) {
            //一段校验逻辑
            final String a = argument.a;
            final int b = argument.b;
            if (a == null || b > 10 || b < 0) {
                throw new RuntimeException("argument is not valid.");
            }

            String result = "not inited.";
            Throwable throwable = null;
            try {
                final boolean c = argument.c;
                if (c) {
                    result = a;
                    return result;
                } else {
                    result = String.valueOf(integerCalculator.calculate(b));
                    return result;
                }
            } catch (Throwable t) {
                throwable = t;
                throw t;
            } finally {
                // 通常是统计和上报
                if (throwable == null) {
                    System.out.printf("result is %s", result);
                } else {
                    System.out.printf("result is %s, throwable message is %s,", result, throwable.getMessage());
                }
            }
        }

很明确的,抽取了a,b,c三个变量.通过idea,不论是观察高亮,还是查找argument变量的引用,都能很快确定除了初始化局部变量,已经没有对其的引用了.

第二步将函数内的局部变量转为context对象的public属性

第二步就是将上述三个函数内的变量放到一个对象的属性里,这个对象我通常起名为xxContext,这个对象并不是为了在不同的位置复用的,它只供这个地方使用,所以名字可以跟业务非常耦合,比如这里叫做GetBizResultContext.

        public static class GetBizResultContext{
            public final String a;
            public final int b;
            public boolean c;

            public GetBizResultContext(Argument argument) {
                a = argument.a;
                b = argument.b;
            }

            public void setC(final boolean c) {
                this.c = c;
            }
        }

读者可能很奇怪,这几个变量不是跟Argument长得一模一样吗?

没错,在这个例子里,它确实长得是一模一样,因为这个实例代码的入参恰好只有argument一个.有时候我们的参数其实是多个,如getBizResult(Argument argument,Object... otherArgs),那么,这个Context的构造函数就会是xxxContext(Argument argument,Object... otherArgs),也就是理论上跟函数的入参一致.而且它的所有参数,都是public的,这是因为改造过程中idea暂时没有抽取context的能力,为了改造getBizResult的时候更稳妥(在业务函数中访问变量的前面只要加上getBizResult.),特意如此安排的.此时getBizResult函数里是这样的:

public String getBizResult(Argument argument) {
            final GetBizResultContext getBizResultContext = new GetBizResultContext(argument);
            //一段校验逻辑
            if (getBizResultContext.a == null || getBizResultContext.b > 10 || getBizResultContext.b < 0) {
                throw new RuntimeException("argument is not valid.");
            }

            String result = "not inited.";
            Throwable throwable = null;
            try {
                getBizResultContext.c = argument.c;
                if (getBizResultContext.c) {
                    result = getBizResultContext.a;
                    return result;
                } else {
                    result = String.valueOf(integerCalculator.calculate(getBizResultContext.b));
                    return result;
                }
            } catch (Throwable t) {
                throwable = t;
                throw t;
            } finally {
                // 通常是统计和上报
                if (throwable == null) {
                    System.out.printf("result is %s", result);
                } else {
                    System.out.printf("result is %s, throwable message is %s,", result, throwable.getMessage());
                }
            }
        }
    }

可能刚刚有眼尖的朋友注意到,a和b是final的,c不是.这是为啥?因为c的赋值在函数中间有一次赋值,最快速稳妥的办法,是将这里改为对context的c的赋值,而不是在构造函数里初始化.如果想将这段逻辑移入context的构造函数,必须满足以下两个条件:

在第二步抽取函数的局部变量的时候,这里是final的.也就是它后续没有编辑;
c的初始化没有使用context有关的任意变量.如果它用到了,那么你必须继续保证这几个变量在此赋值前没有发生变化的可能.

第一个条件很容易满足,因为在idea重构的时候,如果c后续没有再次赋值的话,会自动在函数局部变量c的声明处添加final修饰符.但是第二个条件要想满足,需要非常小心赋值的语句里有没有其它跟argument有关的变量,以及这些变量是否有变化.假如有改造前有如下代码:

public String getBizResult(Argument argument) {
//参数规整
...
    argument.b = argument.b > 10? -10: argument.b;
...
    argument.c = argument.b > 0;
...
}

那么改造后的c是绝对不能放到context的构造函数里的,因为在这个阶段,b还没有规整过,c的处理可能是错的.因此最简单的办法,就是让c在原有抽取变量所在的位置set到context中,不用严格的验证c的初始化是否跟其它参数是正交(也就是跟其它参数没有任何关系)的了.

第三步将context的public转为private

改造的第三步非常简单:通过idea,将context里的public属性改为private.

读者会对此很惊讶:刚刚还强调要public,现在怎么要改为private了呢?

正如我刚才括号里写的,第二步里使用public,是因为在没有idea的重构功能加持下,为了保证每一个地方都改对,特意使用public.比如原来是result = a;的地方,现在是result = getBizResultContext.a;,编辑的时候并不容易出错.而现在改成private,是为了访问的方式改为函数,当需要复用的时候,可以轻易抽取接口,正如我所说,context不是为了复用而抽取的对象.为什么context不是复用的对象呢?因为它耦合了参数校验和规整,业务逻辑和上报三段逻辑所需要的字段,并不容易复用.

修改修饰符idea会帮我们很快完成,此时业务逻辑变成了这样:

        public String getBizResult(Argument argument) {
            final GetBizResultContext getBizResultContext = new GetBizResultContext(argument);
            //一段校验逻辑
            if (getBizResultContext.getA() == null || getBizResultContext.getB() > 10 || getBizResultContext.getB() < 0) {
                throw new RuntimeException("argument is not valid.");
            }

            String result = "not inited.";
            Throwable throwable = null;
            try {
                getBizResultContext.setC(argument.c);
                if (getBizResultContext.isC()) {
                    result = getBizResultContext.getA();
                    return result;
                } else {
                    result = String.valueOf(integerCalculator.calculate(getBizResultContext.getB()));
                    return result;
                }
            } catch (Throwable t) {
                throwable = t;
                throw t;
            } finally {
                // 通常是统计和上报
                if (throwable == null) {
                    System.out.printf("result is %s", result);
                } else {
                    System.out.printf("result is %s, throwable message is %s,", result, throwable.getMessage());
                }
            }
        }

第四步将流水账内的每一个功能转为一个private函数

这步之后就非常简单了,第四步将三段不同的逻辑分别用idea的抽取函数功能,变成三段函数:

//计算业务结果的过程
        public String getBizResult(Argument argument) {
            final GetBizResultContext getBizResultContext = new GetBizResultContext(argument);
            //一段校验逻辑
            doValidation(getBizResultContext);

            String result = "not inited.";
            Throwable throwable = null;
            try {
                getBizResultContext.setC(argument.c);
                result = getResult(getBizResultContext);
                return result;
            } catch (Throwable t) {
                throwable = t;
                throw t;
            } finally {
                // 通常是统计和上报
                afterBiz(result, throwable);
            }
        }

        private void afterBiz(final String result, final Throwable throwable) {
            if (throwable == null) {
                System.out.printf("result is %s", result);
            } else {
                System.out.printf("result is %s, throwable message is %s,", result, throwable.getMessage());
            }
        } 

        @org.jetbrains.annotations.NotNull
        private String getResult(final GetBizResultContext getBizResultContext) {
            if (getBizResultContext.isC()) {
                return getBizResultContext.getA();
            } else {
                return String.valueOf(integerCalculator.calculate(getBizResultContext.getB()));
            }
        }

        private void doValidation(final GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getA() == null || getBizResultContext.getB() > 10 || getBizResultContext.getB() < 0) {
                throw new RuntimeException("argument is not valid.");
            }
        }

哎,这一看,有个函数的参数还不止context,最好将其改造为只有context的方式:

        //计算业务结果的过程
        public String getBizResult(Argument argument) {
            final GetBizResultContext getBizResultContext = new GetBizResultContext(argument);
            //一段校验逻辑
            doValidation(getBizResultContext);

            getBizResultContext.setResult("not inited.");
            try {
                getBizResultContext.setC(argument.c);
                getResult(getBizResultContext);
                return getBizResultContext.getResult();
            } catch (Throwable t) {
                getBizResultContext.setThrowable(t);
                throw t;
            } finally {
                // 通常是统计和上报
                afterBiz(getBizResultContext);
            }
        }

        private void afterBiz(GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getThrowable() == null) {
                System.out.printf("result is %s", getBizResultContext.getResult());
            } else {
                System.out.printf("result is %s, throwable message is %s,", getBizResultContext.getResult(), getBizResultContext.getThrowable().getMessage());
            }
        }

        private void getResult(final GetBizResultContext getBizResultContext) {
            if (getBizResultContext.isC()) {
                getBizResultContext.setResult(getBizResultContext.getA());
            } else {
                getBizResultContext.setResult(String.valueOf(integerCalculator.calculate(getBizResultContext.getB())));
            }
        }

        private void doValidation(final GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getA() == null || getBizResultContext.getB() > 10 || getBizResultContext.getB() < 0) {
                throw new RuntimeException("argument is not valid.");
            }
        }

第五步将上述private函数抽象到接口的default实现里

接下来,也就是第五步,可以将doValidation,getResult和afterBiz单独抽取到接口的default方法里.要注意的是getResult里有一个注入的函数integerCalculator,抽取的时候需要改为接口的函数.改造后是这样的:

public class Test {
    //业务的实现类
    public static class Biz implements BizAfterwards,BizProvider,BizValidator{

...

    public interface BizAfterwards{
        default void afterBiz(Biz.GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getThrowable() == null) {
                System.out.printf("result is %s", getBizResultContext.getResult());
            } else {
                System.out.printf("result is %s, throwable message is %s,", getBizResultContext.getResult(), getBizResultContext.getThrowable().getMessage());
            }
        }
    }

    public interface BizValidator{
        default void doValidation(final Biz.GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getA() == null || getBizResultContext.getB() > 10 || getBizResultContext.getB() < 0) {
                throw new RuntimeException("argument is not valid.");
            }
        }
    }

    public interface BizProvider{
        default void getResult(final Biz.GetBizResultContext getBizResultContext) {
            if (getBizResultContext.isC()) {
                getBizResultContext.setResult(getBizResultContext.getA());
            } else {
                getBizResultContext.setResult(String.valueOf(getIntegerCalculator().calculate(getBizResultContext.getB())));
            }
        }
        IntegerCalculator getIntegerCalculator();
    }

单元测试

重构结束了,是不是各个业务逻辑已经单独抽取了?如果需要写单元测试,那就非常简单了,比如针对BizProvider.getBizResult做单元测试:

class TestTest extends Specification {

    def "test testBizResult"() {
        given:
        def provider = new Test.BizProvider() {
            @Override
            Test.IntegerCalculator getIntegerCalculator() {
                return new Test.IntegerCalculator(){
                    @Override
                    Integer calculate(final Integer integer) {
                        return 10;
                    }
                }
            }
        }
        def context = new Test.Biz.GetBizResultContext(new Test.Biz.Argument.ArgumentBuilder().a("content a").b(9).c(false).build())
        when:
            provider.getResult(context);
        then:
        context.result == "10"
    }
}

单元测试里所有的外部依赖自然不需要真正的实现,只要返回你定义的某个结果就可以了.

能力复用

看到这里,其实大家现在做重构和单元测试的目的达到了,但是当我们需要复用的时候呢?

首先先将default函数里的context要换成interface,比如getBizResult改成某interface,然后将函数里的get函数都自动生成,再将原有的context改为实现该接口,即可将该能力提供在其它地方复用了.比如:

 public static class GetBizResultContext implements BizArg{
 ...
 }
 
 public interface BizProvider{
        default void getResult(final BizArg getBizResultContext) {
            if (getBizResultContext.isC()) {
                getBizResultContext.setResult(getBizResultContext.getA());
            } else {
                getBizResultContext.setResult(String.valueOf(getIntegerCalculator().calculate(getBizResultContext.getB())));
            }
        }
        IntegerCalculator getIntegerCalculator();
    }

    public interface BizArg{

        boolean isC();

        String getA();

        int getB();

        void setResult(String a);
    }

这个过程只需要:

新增BizArg接口
将BizProvider的函数参数改为BizArg接口
将GetBizResultContext实现自BizArg接口
修复BizProvider对BizArg的几个接口的实现

这样BizProvider就做好了对外的复用准备了,是不是特别简单?

完整的示例

最后这是完整的类:


import jetbrick.util.annotation.NotNull;
import jetbrick.util.annotation.Nullable;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.NoArgsConstructor;

public class Test {
    //输出业务计算的结果
    public static void main(String[] args) {
        final Biz.Argument argument = Biz.Argument.builder()
                .a("content a")
                .b(9)
                .c(false)
                .build();

        new Biz().getBizResult(
                argument
        );
    }

    //业务的实现类
    public static class Biz implements BizAfterwards,BizProvider,BizValidator{

        //通常是注入的外部服务
        private volatile IntegerCalculator integerCalculator;

        {
            integerCalculator = new IntegerCalculator();
        }

        @Override
        public IntegerCalculator getIntegerCalculator() {
            return integerCalculator;
        }

        @AllArgsConstructor
        @Builder
        @NoArgsConstructor
        public static class Argument {
            String a;
            int b;
            boolean c;
        }

        public static class GetBizResultContext implements BizArg{
            private final String a;
            private final int b;
            private boolean c;
            private String result;
            private Throwable throwable;

            public GetBizResultContext(Argument argument) {
                a = argument.a;
                b = argument.b;
            }

            @Override
            public String getA() {
                return a;
            }

            @Override
            public int getB() {
                return b;
            }

            @Override
            public boolean isC() {
                return c;
            }

            public void setC(final boolean c) {
                this.c = c;
            }

            @Override
            public void setResult(final String result) {
                this.result = result;
            }

            public String getResult() {
                return result;
            }

            public void setThrowable(final Throwable throwable) {
                this.throwable = throwable;
            }

            public Throwable getThrowable() {
                return throwable;
            }
        }

        //计算业务结果的过程
        public String getBizResult(Argument argument) {
            final GetBizResultContext getBizResultContext = new GetBizResultContext(argument);
            //一段校验逻辑
            doValidation(getBizResultContext);

            getBizResultContext.setResult("not inited.");
            try {
                getBizResultContext.setC(argument.c);
                getResult(getBizResultContext);
                return getBizResultContext.getResult();
            } catch (Throwable t) {
                getBizResultContext.setThrowable(t);
                throw t;
            } finally {
                // 通常是统计和上报
                afterBiz(getBizResultContext);
            }
        }
    }

    public interface BizAfterwards {
        default void afterBiz(Biz.GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getThrowable() == null) {
                System.out.printf("result is %s", getBizResultContext.getResult());
            } else {
                System.out.printf("result is %s, throwable message is %s,", getBizResultContext.getResult(), getBizResultContext.getThrowable().getMessage());
            }
        }
    }

    public interface BizValidator{
        default void doValidation(final Biz.GetBizResultContext getBizResultContext) {
            if (getBizResultContext.getA() == null || getBizResultContext.getB() > 10 || getBizResultContext.getB() < 0) {
                throw new RuntimeException("argument is not valid.");
            }
        }
    }

    public interface BizProvider{
        default void getResult(final BizArg getBizResultContext) {
            if (getBizResultContext.isC()) {
                getBizResultContext.setResult(getBizResultContext.getA());
            } else {
                getBizResultContext.setResult(String.valueOf(getIntegerCalculator().calculate(getBizResultContext.getB())));
            }
        }
        IntegerCalculator getIntegerCalculator();
    }

    public interface BizArg{

        boolean isC();

        String getA();

        int getB();

        void setResult(String a);
    }

    //外部服务的实现,现实生活中实现通常是远端服务,这里写出来实现只是为了跑通测试
    //我们开发者只基于接口约束开发,对于其实现有没有bug不负责
    public static class IntegerCalculator {
        @NotNull
        public Integer calculate(@Nullable Integer integer) {
            if (integer == null) {
                return 0;
            }
            return integer * integer;
        }
    }
}

待续

没错,到这里,其实改造还没彻底结束.提供了能力的接口要怎么管理呢?这个得结合你项目的设计,考虑要不要把一些目的一致的能力做成命令模式,把一些几乎一致的context变成状态机.这个改造本身只是减少了耦合,提高了复用,但是怎么能让后续维护的同事易维护,还是需要花费不少心思的.

这就是我近期总结的如何对流水账代码安全地做重构和单元测试.如果大家有什么好的方法,不论是代码重构还是单元测试,都欢迎在评论区里留言.

尚弟的小笔记

一个特殊字符与一下午

Java8Stream用法整理

BaseStream

Stream

tcpdump排查现网问题两例

浅谈Java开发中Redis的使用姿势

使用建议

命名规范

避免使用 bigkey

使用高效的序列化和压缩方法

使用整数对象共享池

利用Hash优化缓存

尽可能减少存储的数据量

只用来保存热数据

不同的业务数据分实例存储

数据保存时，设置合理的过期时间

控制每个Redis实例的容量

线上禁用命令

慎用MONITOR命令

慎用全量操作命令

常见问题

雪崩

穿透

击穿

缓存污染

一致性问题

HotKey问题

事务里分布式锁失效

为什么是Redisson而不是自己写分布式锁

解决linux无法启动tigervnc服务器的问题

走近DDD

为什么需要DDD？

那么 DDD 怎么解决这些问题？

DDD是什么呢?

那么怎么做DDD呢?

战略设计

限界上下文分离领域模型

限界上下文发展通用语言

使用子域处理遗留系统

使用上下文映射来集成多个限界上下文

战术设计

聚合怎么设计

领域事件怎么设计

进度加速和项目管理工具

事件风暴

时间评估工具

常见的DDD误区：

后记

提升个人影响力的简单原则

走进Lombok

Lombok 是什么

Lombok 怎么用

Pojo代码生成类

@Getter @Setter

@NoArgsConstructor @AllArgsConstructor @RequiredArgsConstructor

@ToString @EqualsAndHashCode

@Data @Value

@Builder @Singular

@With

语义增强类

@CustomLog

@SneakyThrows

@Synchronized

变量的注入和局部变量增强类

@Cleanup

@val @var

Lombok 的原理

Lombok 的注意事项

构造函数的易变性

默认构造函数的丢失问题 @AllArgsConstructor @Builder

注解的继承问题

Kotlin与Lombok的集成问题

附： 阅读 Lombok项目

在Mac上打开Iterm或终端时重建tab

Java流水帐代码的重构与单元测试

背景

改造方案

具体操作

第一步 将流水账函数的参数访问,变为函数内的局部变量

附：阅读 Lombok项目

第一步将流水账函数的参数访问,变为函数内的局部变量

第二步将函数内的局部变量转为context对象的public属性

第三步将context的public转为private

第四步将流水账内的每一个功能转为一个private函数

第五步将上述private函数抽象到接口的default实现里