延迟加载的对象列表的接口

时间:2020-06-26 23:08:36

标签: java list rest interface lazy-loading

我们有一堆数据源,我们在其中查询一些REST API或其他数据源,并获取对象列表。我正在尝试设计一个抽象层,该层不需要知道如何联系任何特定的API实例或如何从语义上解释这些对象,但是可以确保我们从实现了所需接口的任何类中获取对象列表当时。

我希望有时结果的数量会很大(但总是有限的!),并且检索往往很慢,所以我需要一些东西不能一次将所有内容都加载到内存中,而是允许列表的结果在它们可用时一起工作。如果列表在nexthasNext或任何合适的类似物中屏蔽,我很好。

实现这些目标的最合适的抽象/方法是什么?如何实现?

我的直觉告诉我,它应该是某种Java 8 Streams风格的,可能是通过Java 9 Stream.iterate方法创建的,但是我对函数式编程范例不太熟悉,并且对于我弄清楚了如何在REST调用中可用时填充Stream的元素,并在完成时将其关闭。

1 个答案:

答案 0 :(得分:1)

事实证明,我混淆了两个问题:如何在接口中提供Iterator(这很简单),以及如何在后台填充该Iterator。我最终得到以下内容:

创建一个实现Iterator的自定义抽象类。该类具有一个内部BlockingQueue和一个内部List。它还定义了一种抽象方法,该方法旨在在一次调用中执行人口的所有活动。

第一次调用hasNext()时,启动一个守护程序线程,该线程调用该抽象方法。然后,当线程处于活动状态(表示仍在填充BlockingQueue)或列表不为空(表示并非所有元素都已通过next()消耗了)时,对BlockingQueue进行轮询,直到它中至少有一个元素为止。它。完成后,删除该元素并将其添加到列表中。 next()仅返回列表中的元素。

这会导致延迟加载(直到第一次调用hasNext()之前,什么都不会发生)也将在后台异步发生-调用者将能够在事物可用时立即对其进行处理({ {1}}将在无法使用的情况下阻塞),并且不会浪费过多的内存(如果BlockingQueue的元素过多,它将阻塞)。

相关问题