我们不确定如何对应用程序的一部分进行基准测试，其中多个线程（生产者）写入单个 ConcurrentHashMap。此外，如果达到特定大小，单个消费者线程会用空的地图切换地图。map 的切换是必要的，因为生产者线程需要尽可能快地写入 map，而不会产生额外的拥塞。消费者线程还处理地图的元素并将它们存储在缓冲区中。最后，另一个线程会将缓冲区内容发送到应用程序的其他一些组件。
我们不清楚如何测量将元素写入 ConcurrentHashMap 直到它们准备好发送（-> 聚合吞吐量）所需的时间（和相应的吞吐量）。目前，我们排除了发送元素以简化操作。我们知道吞吐量受到地图大小的限制。但是，我们希望对其进行测量以将其与未来实现的吞吐量进行比较。
到目前为止，我们调查了以下场景：
Silo-Test
该基准测试将测量单个基准测试中的每个步骤。基准 A：将元素插入 Map 直到达到大小（= batchSize）。基准 B：测量元素存储在缓冲区中需要多长时间。
优点：相对容易实现。
缺点：通过将基准 A 和 B 加在一起，会丢失线程交互性并且不会给出吞吐量聚合。
Flat-Test
与 Silo-Test 相比，所有步骤都在一个基准测试中执行（单线程）。首先将 X 元素插入 Map，然后切换 Map，处理 X 元素并将其存储到缓冲区中。
优点：相对容易实现。
缺点：线程交互性丢失，基准测试只能由一个线程（-> 只有一个生产者）运行，因为当前实现不支持同时切换映射和元素处理。
Dynamic-Amount-Test（首选测试）
基准测试方法将在每次调用时将单个元素插入到映射中。消费者线程将在@Setup 阶段启动，并在测试期间将元素传递到缓冲区。在基准测试结束时，缓冲区中收集的元素计数被提供给 JMH 用于结果计算，而不是使用基准方法的调用。我们不知道这种开箱即用的功能允许我们在基准测试结束时向 JMH 提供缓冲区大小。很可能我们需要修改 JMH 来满足这个要求（对吗？）。
优点：组合吞吐量由 JMH
缺点计算：没有开箱即用的功能，JMH 修改可能很危险（影响测量，基准有效性不清楚）
附加说明：在这种情况下，我们还必须处理非稳态基准。我们考虑过使用 JMH 的批处理可能性并使用不同的大小进行测试。
预先感谢任何建设性的回应。