为什么我的Spring集成拆分和聚合在处理一个大列表时会逐渐变慢？

我正在尝试使用Spring转换一个大列表（超过100万个条目）中的所有条目。我已将我的用例简化为以下Spring Boot应用程序：

@SpringBootApplication
@IntegrationComponentScan
public class IntegrationTestApplication implements CommandLineRunner {

    private static final Logger logger = LoggerFactory.getLogger(IntegrationTestApplication.class);

    @Autowired
    private IntegrationTestGateway integrationTestGateway;

    public static void main(String[] args) {
        SpringApplication.run(IntegrationTestApplication.class, args);
    }

    @Bean
    public IntegrationFlow splitAndAggregate() {
        return f -> f
                .split()
                .<Integer, String>transform(this::integerToString)
                .aggregate();
    }

    public String integerToString(Integer i) {
        logger.info("Converting {}.", i);
        return i.toString();
    }

    @Override
    public void run(String... args) {
        List<Integer> integers = new Random().ints(1000000, 0, 100).boxed().collect(Collectors.toList());
        List<String> strings = integrationTestGateway.integersToStrings(integers);
    }

    @MessagingGateway
    private interface IntegrationTestGateway {
        @Gateway(requestChannel = "splitAndAggregate.input")
        List<String> integersToStrings(List<Integer> integers);
    }
}

但是，在处理了大约130000个条目后，每条消息之间的延迟超过100毫秒：

2016-10-10 08:11:19.710  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 64.
2016-10-10 08:11:19.868  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 3.
2016-10-10 08:11:20.015  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 18.
2016-10-10 08:11:20.174  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 42.
2016-10-10 08:11:20.302  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 0.
2016-10-10 08:11:20.468  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 16.
2016-10-10 08:11:20.607  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 6.
2016-10-10 08:11:20.749  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 46.
2016-10-10 08:11:20.902  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 82.
2016-10-10 08:11:21.043  INFO 48589 --- [main] s.s.IntegrationTestApplication           : Converting 23.

在我的实际代码中，在处理了500K条目的输入之后，这个延迟已经增加到5秒以上

---

有什么办法可以加快速度吗？如果可能的话，我仍然希望使用Spring集成，因为我的实际用例更复杂，需要线程等等，默认代码有一个阻止添加具有现有序列号的消息的检查-这会导致对当前消息内容进行线性搜索，从而导致您看到的行为

仅当发布策略为

SequenceSizeReleaseStrategy

时，才可执行此操作

如果您使用定制的发布策略，那么您可以避免这种检查，在这种情况下这是不必要的

请尝试以下操作：

.aggregate(a -> a.releaseStrategy(new MyReleaseStrategy()))

及

---

我添加了一个。

谢谢，这为我指明了正确的方向，尽管

group.getOne（）.getHeaders（）.get（IntegrationMessageHeaderAccessor.SEQUENCE\u NUMBER，Integer.class）

总是为我返回

1

。我已经用对我有用的返回声明更新了答案，并将在更改获得批准后接受；谢谢doh-我唯一的借口是凌晨4点：）-我的建议应该是

序列大小（不是…数字），但你的建议更优雅，尽管它做同样的事情）。
.aggregate(a -> a.releaseStrategy(new MyReleaseStrategy()))

public static class MyReleaseStrategy implements ReleaseStrategy {

    @Override
    public boolean canRelease(MessageGroup group) {
        return group.getSequenceSize() == group.size();
    }

}