wang-jiahua opened a new pull request, #10485: URL: https://github.com/apache/rocketmq/pull/10485
### Which Issue(s) This PR Fixes Fixes #10481 ### Brief Description Builds on top of #10443 (which introduces the typed `LABEL_*_KEY` constants). After `AttributeKey` instances are de-duplicated by #10443, the next allocation hot spot in the metrics path is the `Attributes` object itself. For repeated parameter combinations the broker keeps rebuilding identical immutable `Attributes` (each ~200–300 byte). This PR introduces a two-level cache (volatile inline cache + `ConcurrentHashMap` fallback) at three points: 1. **`BrokerMetricsManager.getOrBuildTopicAttributes(topic, msgType, isSystem)`** — 4-field volatile inline cache + CHM keyed by `topic|msgType|isSystem`. 2. **`RemotingMetricsManager.getOrBuildAttributes(reqCode, respCode, isLongPolling, result)`** — long-packed cache key (35 bits across 4 args, no `String` allocation), volatile inline cache + CHM. Falls back to direct build for unknown `result` values. 3. **`RemotingCodeDistributionHandler`** — replace two independent `volatile` fields (`lastCode`, `lastAdder`) with an immutable `CachedCounter` holder published through a single `volatile` reference. A single `volatile` read per `inc()` returns a self-consistent `(code, adder)` snapshot, eliminating a torn-read between the two fields under `@Sharable` concurrent access from multiple Netty `EventLoop` threads. ### Dependency This PR is **stacked on top of #10443** (which provides the typed `LABEL_*_KEY` constants used by the cache builders). Until #10443 is merged, the diff against `develop` will include both PRs' changes (8 + 3 = 11 files). After #10443 is merged, this PR will be rebased onto `develop` and the diff will reduce to the 3 files in scope of this PR (105 +/-1 lines). ### How Did You Test This Change? - Existing `BrokerMetricsManagerTest` (27 tests) passes. - Manual verification of cache hit / miss paths for both inline cache and CHM fallback. - The `CachedCounter` change is reviewed against the original two-`volatile` design; the immutable holder is the standard idiom for atomically publishing a multi-field state under JMM (`final` field semantics + single `volatile` read). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
