So, weren't sure about the concurrency implications of how both Hysterix and Prometheus might interact with this system per this comment: https://github.com/prometheus/client_java/pull/15#discussion-diff-10875050R341?  What you have in this current commit will unfortunately neither be atomic nor safe from race conditions.  Here is what you would need to do with the current approach (pseudocode snippet):

```
ConcurrentMap<String,Metric> metrics = …;

// 1. Note the call to registerStatic(false).
// 2. Note the null check from the ConcurrentMap putIfAbsent call.
if (metrics.putIfAbsent(name, Gauge.newBuilder().….registerStatic(false)….build()) == null) {
  // Here we are registering the metric.
  Prometheus.defaultRegister(metrics.get(name));
}
```

That's not pretty.  I would take the following approach since it *much safer* and can you can rely on the concurrency guarantees of the Prometheus library itself and it is just "less clever":

1. Declare these [metrics concretely as statics in your class](https://github.com/prometheus/client_java/blob/master/utility/hotspot/src/main/java/io/prometheus/client/utility/hotspot/Hotspot.java#L47).

2. The ``Metric.Builder`` objects are immutable and can be used for templatizing, which enables you to reduce the amount of duplication you need to write.  Here [we declare the namespace once](https://github.com/prometheus/client_java/blob/master/utility/jvmstat/src/main/java/io/prometheus/client/utility/jvmstat/JvmstatMonitor.java#L82).  Here [we add the subsystem](https://github.com/prometheus/client_java/blob/master/utility/jvmstat/src/main/java/io/prometheus/client/utility/jvmstat/JvmstatMonitor.java#L392).  Finally [we build the concrete metric](https://github.com/prometheus/client_java/blob/master/utility/jvmstat/src/main/java/io/prometheus/client/utility/jvmstat/JvmstatMonitor.java#L320).  Note that in this jvmstat example, we are conditionally defining and registering metrics due to a lot of nuance that is endemic in the Java Virtual Machine.  The Hysterix case has pretty well-defined metrics involved, so you probably will not need to use the atomic set approach that you in the citation; just look at the templating.

3. Attach reference to the concrete metric in the mutation ``Callable`` or ``Runnable`` of yours.