起因
群里黑神抛出了一个问题，意图引起大家的思考
image.png
黑神简单解释之后，群里仍有同学不太理解
正好之前笔者在Supplier上有一些实践，因此打算跟大家分享一下使用经验
基础知识
JDK1.8为我们提供了一个函数接口Supplier，先来看一下它的接口定义
@FunctionalInterface
public interface Supplier<T> {
/**
* Gets a result.
*
* @return a result
*/
T get();
}
从接口的定义可以看出，它代表了这样的一类函数：无入参，有一个返回值。
接口越简单，看的越糊涂，这代表了什么含义？如此简单的接口，存在的必要性是什么？
接着再看下该接口的java doc描述
Represents a supplier of results.
There is no requirement that a new or distinct result be returned each time the supplier is invoked.
This is a functional interface whose functional method is get().
java doc的描述，更是让人云里雾里
实践
为了代入场景，直接用大家开发过程中经常能碰到，但稍不注意却会掉坑里的问题做为案例进行讲解。
案例一
首先思考一个问题：如何输出日志？(So easy)
log.info("print info log");
接着，如何输出调试日志(debug)？（So easy）
log.debug("print debug log");
测试(开发)环境与线上环境的日志级别一般不同。测试环境为了调试，一般会开启debug级别，输出一些调试信息便于问题排查；而线上环境一般是处于稳定状态，不太需要输出调试信息，再出于性能考虑，一般会开启info级别，过滤掉debug日志。
再接着，如果输出的日志里，不再仅仅是简单的句子，而有时候需要包含一个对象(例如远程调用的入参、出参)，怎么办？
log.debug("invoke remote method, return value: {}", JSON.toJSONString(returnVal));
稍一疏忽，很容易写出上述代码(大家可以搜一下自己负责的项目，看看是否到处充斥这样的代码)，究其原因，是被log.debug()的外表所欺骗与迷惑：log.debug()只会在开启debug级别的日志下输出日志，而线上日志级别是info，不会输出，因此没有性能问题。
诚然，在开启info级别时，这条日志并不会输出，但这里容易被忽视的点是，无论开启何种日志级别，JSON.toJSONString(returnVal)这段代码都会首先被执行，返回值做为log.debug入参后，才会根据日志级别判断是否输出日志。也即是说，即便最终判断不输出日志，也会执行一遍序列化方法。这在被序列化对象很大的时候，容易造成性能问题。(曾经见过输出一屏都装不下的日志，序列化耗时50-70ms)
如何解决？
if (log.isDebugEnabled()) {
log.debug("invoke remote method, return value: {}", JSON.toJSONString(returnVal));
}
即先判断，再输出
但是程序员天性懒惰(懒惰是科技进步的动力)，原来一行代码能解决的事，现在三行代码才能完成，不能忍啊！而且如果需要输出的调试日志有很多，就会出现满屏if(log.isDebugEnabled())，代码会很丑陋，阅读代码时候很容易被干扰正常逻辑
解决方案：Supplier
首先定义一个Lazy类，用于延迟计算(懒加载)
public class Lazy<T> implements Supplier<T> {
private Supplier<T> supplier;
public static <T> Lazy<T> of(Supplier<T> supplier) {
Objects.requireNonNull(supplier, "supplier is null");
if (supplier instanceof Lazy) {
return (Lazy) supplier;
} else {
return new Lazy(supplier);
}
}
private Lazy(Supplier<T> supplier) {
this.supplier = supplier;
}
@Override
public T get() {
return supplier.get();
}
@Override
public String toString() {
return supplier.get().toString();
}
}
这时候，日志的输出就变成了
log.debug("invoke remote method, return value: {}", Lazy.of(() -> JSON.toJSONString(returnVal)));
一行代码，实现了原来三行代码才能实现的功能：判断是否满足输出条件，满足，则执行计算，即延迟计算--->序列化；不满足，则不计算，不执行序列化。
以Logback中的源码为例
public void debug(String format, Object arg) {
filterAndLog_1(FQCN, null, Level.DEBUG, format, arg, null);
}
private void filterAndLog_1(final String localFQCN, final Marker marker, final Level level, final String msg, final Object param, final Throwable t) {
final FilterReply decision = loggerContext.getTurboFilterChainDecision_1(marker, this, level, msg, param, t);
if (decision == FilterReply.NEUTRAL) {
// 不满足输出条件，直接返回
if (effectiveLevelInt > level.levelInt) {
return;
}
} else if (decision == FilterReply.DENY) {
return;
}
// 满足输出条件，才会执行Lazy.toString()，即supplier.get().toString()
buildLoggingEventAndAppend(localFQCN, marker, level, msg, new Object[] { param }, t);
}
每次执行这一行代码，会生成一个Supplier实例(Lazy)，并做为log.debug入参，在log.debug中进行判断决定是否要使用该Lazy，即调用Lazy.toString()，如此便达到了延迟计算的效果。
只谈优点不谈缺点有耍流氓的嫌疑：很显然，每次执行会生成一个Supplier实例。但是我们仔细思考一下：
- 我们生成的实例对象并不包含复杂的属性，很轻量，一次分配不需要占用太多空间
- 代码所在方法的生命周期一般比较短，符合朝生夕死的特点
实例对象因此会在TLAB或者Young Gen上被分配，并且几乎没有机会晋升到Old Gen就会被回收。
因此，这个缺点也就不复存在。
案例二
// code1
Long price = Optional.ofNullable(sku)
.map(Sku::getPrice)
.orElse(0L);
// code2
Long price = Optional.ofNullable(sku)
.map(Sku::getPrice)
.orElseGet(() -> 0L);
Optional作为一种判空的优雅解决方案，会在我们的日常开发中经常使用到，上面两种写法，使用更多的应该是code1：sku或者sku.price中只要任意一个为空，最终价格都为0;code2写法，在这种情况下，会显得很鸡肋，而且也不好理解，为什么有了orElse方法，还额外提供一个orElseGet方法。
再看下面两种方式，稍稍有些区别
// code3
Object object = Optional.ofNullable(getFromCache())
.filter(obj -> validate(obj))
.orElse(selectFromDB()); // here
// code4
Object object = Optional.ofNullable(getFromCache())
.filter(obj -> validate(obj))
.orElseGet(() -> selectFromDB()); // here
// Optional
public T orElseGet(Supplier<? extends T> other) {
return value != null ? value : other.get();
}
含义是：先从缓存中获取对象，然后做一下过滤，如果缓存为空或者过滤之后为空，就重新从DB中加载对象。
这时候，orElse或者orElseGet里提供的对象，不再是一个简单的数值，而是一个需要经过计算的对象(言外之意：有额外的加载成本)。orElseGet 在此处的作用显而易见：code3中，无论什么情况，都会执行一遍selectFromDB方法，而code4只有缓存为空或过滤之后为空，才会执行selectFromDB方法，即延迟计算(懒加载)。
总结
Supplier提供了一种包裹代码的能力，被包裹的代码并非实时执行，而是在真正需要使用的时候，被包裹代码段才会被执行，实现延迟计算(懒加载)的效果
网友评论