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