有趣的问题。这里有几个问题。毫无疑问，使用Haskell或Lisp不到半页纸就可以解决，但这是Java，所以我们开始吧...。
一个问题是，我们有可变数量的过滤器，而大多数已经展示的示例都是固定的管道。
另一个问题是，一些OP的“过滤器”具有上下文敏感性，例如“按某种顺序排名前50％”。在流的简单
filter(predicate)构造中无法完成此操作。
关键是要认识到，虽然lambda允许将函数作为参数传递（效果很好），但这也意味着它们可以存储在数据结构中，并且可以对它们执行计算。最常见的计算是取多个函数并将它们组合起来。
假设被操作的值是Widget的实例，Widget是一个具有一些明显的getter方法的POJO：
class Widget {
String name() { ... }
int length() { ... }
double weight() { ... }
}
让我们从第一个问题开始，找出如何处理可变数量的简单谓词。我们可以像这样创建谓词列表：
List<Predicate<Widget>> allPredicates = Arrays.asList(
w -> w.length() >= 10,
w -> w.weight() > 40.0,
w -> w.name().compareTo("c") > 0);
给定这个列表，我们可以对它们进行排列组合（可能没有用，因为它们是无序的），或者选择任意子集。假设我们只想应用所有谓词，如何将变量数量的谓词应用于流？有一个 Predicate.and() 方法，它将接受两个谓词并使用逻辑 and 进行组合，返回一个单独的谓词。因此，我们可以取第一个谓词，并编写一个循环来将其与后续谓词相结合，以建立一个由它们全部组成的复合and谓词：
Predicate<Widget> compositePredicate = allPredicates.get(0);
for (int i = 1; i < allPredicates.size(); i++) {
compositePredicate = compositePredicate.and(allPredicates.get(i));
}
这个方法确实有效，但如果列表为空会失败，而且由于我们现在正在进行的是函数式编程，所以在循环中更改变量是过时的。但是！这是一个约简操作！我们可以将所有谓词缩减为和运算符得到一个复合谓词，如下所示：
Predicate<Widget> compositePredicate =
allPredicates.stream()
.reduce(w -> true, Predicate::and);
(信用：我从@venkat_s那里学到了这个技巧。如果你有机会的话，去听他在会议上的演讲吧，他很厉害。)
请注意将w -> true作为reduction的身份值的用法。（这也可以用作循环的compositePredicate的初始值，这样就可以解决零长度列表的情况。）
现在我们有了复合谓词，我们可以编写一个简短的管道，仅将复合谓词应用于小部件：
widgetList.stream()
.filter(compositePredicate)
.forEach(System.out::println);
上下文敏感过滤器
现在我们考虑所谓的“上下文敏感”过滤器，例如表示为“按某种顺序的前50%”，例如重量最高的50%部件。虽然这不是最好的术语，但它与流中到此为止的元素数量有关。
如何使用流实现这样的过滤器呢？除非有人想出了什么聪明的方法，否则我认为我们必须先将元素收集到某个地方（比如列表）才能将第一个元素发射到输出中。 这有点像管道中的sorted() ，在排序所有输入元素之前无法确定要输出的第一个元素。
使用流找到按重量排名前50%的部件的简单方法如下：
List<Widget> temp =
list.stream()
.sorted(comparing(Widget::weight).reversed())
.collect(toList());
temp.stream()
.limit((long)(temp.size() * 0.5))
.forEach(System.out::println);
这并不复杂，但有点繁琐，因为我们必须将元素收集到列表中并分配给变量，才能在50%计算中使用列表的大小。
然而，这种过滤的“静态”表示有限。如果我们想像谓词一样将其链接成具有可变数量元素（其他过滤器或条件）的流，该怎么办呢？
一个重要的观察是，这段代码实际上是在消耗流和发射流之间进行工作。它碰巧在中间有一个收集器，但如果您将一个流链接到其前面并从其后端链接一些内容，那就没人知道了。事实上，标准的流管道操作，如map和filter，每个都将流作为输入并发出流作为输出。所以我们可以自己编写类似这样的函数：
Stream<Widget> top50PercentByWeight(Stream<Widget> stream) {
List<Widget> temp =
stream.sorted(comparing(Widget::weight).reversed())
.collect(toList());
return temp.stream()
.limit((long)(temp.size() * 0.5));
}
一个类似的例子可能是寻找最短的三个小部件：
Stream<Widget> shortestThree(Stream<Widget> stream) {
return stream.sorted(comparing(Widget::length))
.limit(3);
}
现在我们可以编写结合这些有状态过滤器和普通流操作的内容：
shortestThree(
top50PercentByWeight(
widgetList.stream()
.filter(w -> w.length() >= 10)))
.forEach(System.out::println);
这样做是有效的，但读起来有点糟糕，因为它是“从里到外”并且是倒序的。流源是widgetList，通过普通谓词进行流式过滤。现在，往回走，应用了前50%的过滤器，然后应用了最短的三个过滤器，最后在末尾应用了流操作forEach。这是有效的，但阅读起来相当令人困惑。而且它还是静态的。我们真正想要的是有一种方法将这些新过滤器放入我们可以操纵的数据结构中，以便例如运行所有排列，就像原始问题中一样。
此时的关键洞察力是，这些新类型的过滤器实际上只是函数，而我们在Java中有函数接口类型，可以将函数表示为对象，以便操纵它们，将它们存储在数据结构中，组合它们等等。获取一个参数类型为某个类型并返回相同类型值的函数接口类型是UnaryOperator。在这种情况下，参数和返回类型是Stream<Widget>。如果我们采用方法引用，例如this::shortestThree或this::top50PercentByWeight，那么结果对象的类型将是
UnaryOperator<Stream<Widget>>
如果我们将它们列入列表中，该列表的类型将为：
List<UnaryOperator<Stream<Widget>>>
呃！嵌套三层的泛型对我来说太多了。(但是Aleksey Shipilev曾经向我展示过一个使用四个嵌套泛型的代码.) 太多泛型的解决方案是定义我们自己的类型。让我们称之为Criterion中的一种新功能。结果发现，将我们的新功能接口类型与UnaryOperator相关联没有太多价值，因此我们的定义可以简单地如下:
@FunctionalInterface
public interface Criterion {
Stream<Widget> apply(Stream<Widget> s);
}
现在我们可以创建如下的条件列表：
List<Criterion> criteria = Arrays.asList(
this::shortestThree,
this::lengthGreaterThan20
);
（我们将在下面解释如何使用此列表。）这是一个进步，因为现在我们可以动态地操作列表，但它仍然有些限制。首先，它不能与普通谓词结合使用。其次，这里有很多硬编码的值，比如最短的三个：两个或四个怎么办？除了长度之外，还有其他标准吗？我们真正想要的是一个为我们创建这些Criterion对象的函数。这很容易使用lambda实现。
这将创建一个根据比较器选择前N个小部件的标准：
Criterion topN(Comparator<Widget> cmp, long n) {
return stream -> stream.sorted(cmp).limit(n);
}
使用比较器创建一个标准，以便选择前p个百分比的小部件：
Criterion topPercent(Comparator<Widget> cmp, double pct) {
return stream -> {
List<Widget> temp =
stream.sorted(cmp).collect(toList());
return temp.stream()
.limit((long)(temp.size() * pct));
};
}
这将从普通谓词创建一个标准：
Criterion fromPredicate(Predicate<Widget> pred) {
return stream -> stream.filter(pred);
}
现在我们有了一种非常灵活的方法来创建条件并将它们放入列表中，可以对它们进行子集或排列等操作：
List<Criterion> criteria = Arrays.asList(
fromPredicate(w -> w.length() > 10),
topN(comparing(Widget::length), 4L),
topPercent(comparing(Widget::weight).reversed(), 0.50)
);
一旦我们有了Criterion对象列表，我们需要找出一种方法来应用所有的Criterion。再次，我们可以使用我们的好朋友reduce将它们全部组合成一个单独的Criterion对象：
Criterion allCriteria =
criteria.stream()
.reduce(c -> c, (c1, c2) -> (s -> c2.apply(c1.apply(s))));
身份函数c -> c非常明确，但第二个参数有点棘手。给定流s，我们首先应用标准 c1 ，然后应用标准 c2 ，并将其包装在一个lambda中，该lambda接受两个Criterion对象 c1 和 c2 ，并返回应用c1和c2的组合到流的lambda，并返回结果流。
现在我们已经组合了所有标准，我们可以将其应用于窗口小部件流，如下所示：
allCriteria.apply(widgetList.stream())
.forEach(System.out::println);
这还有点里外颠倒，但它相当可控。最重要的是，它回答了最初的问题，即如何动态组合条件。一旦标准对象在数据结构中，它们可以被选择、子集化、排列或任何必要的方式进行操作，并且它们都可以被组合成单个标准并使用上述技术应用于流。
函数式编程大师们可能会说：“他刚刚重新发明了……！”这可能是真的。我敢肯定，这已经在某个地方被发明了，但在Java之前，由于lambda，不可能编写使用这些技术的Java代码。
更新2014-04-07
我清理了并发布了完整的示例代码。
Predicate<T> p = p1.and(p2).and(p3).and(p4)。 - Edwin Dalorzofilter()操作表达这种条件并不明显。 - Stuart Marks