关于延迟加载的一些应用实践

Holder的实例被创建时，其中的Heavy实例还没有被创建。下面我们假设有三个线程会调用getHeavy方法，其中前两个线程会同时调用，而第三个线程会在稍晚的时候调用。

当前两个线程调用该方法的时候，都会调用到createAndCacheHeavy方法，由于这个方法是同步的。因此第一个线程进入方法体，第二个线程开始等待。在方法体中会首先判断当前的heavy是否是HeavyInstance的一个实例。

如果不是，就会将heavy对象替换成HeavyFactory类型的实例。显然，第一个线程执行判断的时候，heavy对象还只是一个Supplier的实例，所以heavy会被替换成为HeavyFactory的实例，此时heavy实例会被真正的实例化。

等到第二个线程进入执行该方法时，heavy已经是HeavyFactory的一个实例了，所以会立即返回（即heavyInstance）。当第三个线程执行getHeavy方法时，由于此时的heavy对象已经是HeavyFactory的实例了，因此它会直接返回需要的实例（即heavyInstance），和同步方法createAndCacheHeavy没有任何关系了。

以上代码实际上实现了一个轻量级的虚拟代理模式(Virtual Proxy Pattern)。保证了懒加载在各种环境下的正确性。

还有一种基于delegate的实现方式更好理解一些：触发findFirst()这一结束方法的时候才会触发整个Stream链条，每个元素依次经过filter()->map()->findFirst()后返回。所以filter()先处理第一个和第二个后不符合条件，继续处理第三个符合条件，再触发map()方法，最后将转换的结果返回给findFirst()。所以filter()触发了_3_次，map()触发了_1_次。

好，让我们来看一个实际问题，关于无限集合。

Stream类型的一个特点是：它们可以是无限的。这一点和集合类型不一样，在Java中的集合类型必须是有限的。Stream之所以可以是无限的也是源于Stream「懒」的这一特点。

Stream只会返回你需要的元素，而不会一次性地将整个无限集合返回给你。

Stream接口中有一个静态方法iterate()，这个方法能够为你创建一个无限的Stream对象。它需要接受两个参数：

public static Stream iterate(final T seed, final UnaryOperator f)

其中，seed表示的是这个无限序列的起点，而UnaryOperator则表示的是如何根据前一个元素来得到下一个元素，比如序列中的第二个元素可以这样决定：f.apply(seed)。

下面是一个计算从某个数字开始并依次返回后面count个素数的例子：

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!