potential data races #2

[dracestudy]

In addition to our previous issue report, we have found three more races in your repo. When we run testMetricsProcessor, the main thread executes Javametrics.getInstance().addListener(mp). That triggers the initialization of JavametricsImpl singleton, and the drain task scheduled via scheduleAtFixedRate is run on a background thread:

javametrics/javaagent/src/main/java/com/ibm/javametrics/agent/JavaAgent.java

Line 47 in f7e1a5e

exec.scheduleAtFixedRate(this::drain, collectionInterval, collectionInterval, TimeUnit.SECONDS);

The drain path follows the call sequence of (drain -> drainBatched -> emit -> receiveData -> receive -> processData) and processes buffered JSON data.

Meanwhile, the main thread sleeps for three seconds and then calls printSummary. If printSummary runs while the background thread is still updating MetricsContext, the main thread can read gcEvents:

javametrics/javaagent/src/main/java/com/ibm/javametrics/analysis/MetricsContext.java

Line 110 in f7e1a5e

if (gcEvents > 0) {

while the background thread is updating the same variable in aggregateGc:

javametrics/javaagent/src/main/java/com/ibm/javametrics/analysis/MetricsContext.java

Line 82 in f7e1a5e

gcEvents += 1;

By the same reasoning, cpuEvents and cpuSystem, which are updated in aggregateCpu, are also likely to be racy.