[opt](point query) use fastUniqueId instead of UUID.randomUUID to reduce contention

[HonestManXin]

"mysql-nio-pool-52" #340 daemon prio=5 os_prio=0 tid=0x00007f3ac801d800 nid=0x3e35cd waiting for monitor entry [0x00007f39742d7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:215)
	- waiting to lock <0x00007f3f9c218f58> (a sun.security.provider.SecureRandom)
	at sun.security.provider.NativePRNG$RandomIO.implNextBytes(NativePRNG.java:534)
	at sun.security.provider.NativePRNG$RandomIO.access$400(NativePRNG.java:331)
	at sun.security.provider.NativePRNG.engineNextBytes(NativePRNG.java:220)
	at java.security.SecureRandom.nextBytes(SecureRandom.java:468)
	at java.util.UUID.randomUUID(UUID.java:145)
	at org.apache.doris.qe.StmtExecutor.execute(StmtExecutor.java:555)
	at org.apache.doris.qe.MysqlConnectProcessor.handleExecute(MysqlConnectProcessor.java:246)
	at org.apache.doris.qe.MysqlConnectProcessor.handleExecute(MysqlConnectProcessor.java:294)

In high‑concurrency point‑query scenarios, a large number of requests require generating a UUID for internal identification. When the request rate is high, frequent calls to UUID.randomUUID() can introduce contention and become a minor performance bottleneck.

For query, the UUID is only required to provide a unique identifier for request correlation, and cryptographic strength is not necessary. To reduce contention and improve throughput, this change introduces fastUniqueId, which generates RFC‑4122 compatible UUID v4 values using ThreadLocalRandom.

By using a per‑thread random generator instead of the shared random source used by UUID.randomUUID(), UUID generation scales better under high concurrency while still preserving the standard UUID format.

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[HonestManXin]

/review

[HonestManXin]

run buildall

[github-actions]

Review result: no blocking issues found in this PR. The change replaces FE query-id generation in StmtExecutor with a ThreadLocalRandom-based UUID v4-compatible TUniqueId generator, which matches the stated goal of avoiding SecureRandom contention for non-security request correlation IDs.

Critical checkpoint conclusions:

• Goal and tests: The implementation addresses the stated contention source in StmtExecutor query-id generation. Existing CI CheckStyle passed, and I also ran mvn -pl fe-core -DskipTests -Dskip.doc=true checkstyle:check successfully. No dedicated UUID utility unit test is added; residual risk is low because the bit layout is straightforward and mirrors UUID v4 masking.
• Scope: The modification is small and focused: one utility class plus replacements at query/retry/internal-query id generation sites.
• Concurrency: This path is concurrency-related by design. Using ThreadLocalRandom removes the shared SecureRandom monitor contention from these call sites; no shared mutable state or new lock ordering is introduced.
• Lifecycle/static initialization: The SecureRandom holder is lazy and only used by the secure fallback helper, not by the new hot path. No cross-TU/static initialization concern applies in Java here.
• Configuration: No configuration items are added.
• Compatibility/storage format: Generated IDs remain 128-bit TUniqueId values with UUID v4 version/variant bits; no storage, RPC, or mixed-version protocol format change is introduced.
• Parallel paths: The PR updates the StmtExecutor query-id generation sites related to the reported query execution path. Other UUID.randomUUID uses appear to be labels/session IDs/tests and are outside this specific non-cryptographic query-id scope.
• Conditional checks: No new special conditional logic is added.
• Test coverage/results: No result files are changed. CheckStyle passed locally; broader FE UT/compile/performance checks were still pending in GitHub/TeamCity when reviewed.
• Observability: Existing query-id logging/audit behavior is preserved through DebugUtil.printId(TUniqueId). No additional metrics/logs appear necessary.
• Transaction/persistence/data writes: The reviewed changes do not modify transaction, persistence, or data write semantics.
• FE-BE variable passing: No new transmitted field is added; existing TUniqueId propagation is preserved.
• Performance: The hot-path contention issue is improved without obvious added allocation beyond the existing TUniqueId object.

User focus: no additional user-provided review focus was present.

[HonestManXin]

run p0

[HonestManXin]

run p0

[morrySnow]

put it into fe-foundation module

[HonestManXin]

Currently, UUID usages fall into two categories. One generates a UUID and then converts it to a TUniqueId, ultimately only requiring the TUniqueId. Since this path depends on Thrift, the generation of TUniqueId remains in fe-core. The other category only depends on UUID itself, and this part has been moved to fe-foundation.

[HonestManXin]

/review

[HonestManXin]

run buildall

[github-actions]

Code review completed. I did not find a distinct blocking issue in this PR.

Checkpoint conclusions:

• Goal and proof: The change targets UUID.randomUUID() contention in high-concurrency query-id generation and replaces the hot StmtExecutor query-id paths with UniqueIdUtils.fastUniqueId(). The generated IDs preserve UUID v4 version/variant bits and remain suitable for request/query correlation. CI FE UT is still pending; local FE UT could not run because thirdparty/installed/bin/protoc is absent in this runner.
• Scope: The modification is small and focused: two utility classes and four StmtExecutor call sites.
• Concurrency: The changed hot path removes the shared SecureRandom source from normal query-id generation and uses per-thread ThreadLocalRandom; no shared mutable state or locking is added.
• Lifecycle/static initialization: SecureRandom remains lazily initialized only for randomUniqueId(), and the new fast path has no cross-TU/static initialization concern.
• Config/compatibility: No new config, storage format, thrift schema, or FE-BE protocol change is introduced.
• Parallel paths: The PR updates the normal StmtExecutor query execution, retry, and internal query paths. Existing security/user-visible token style UUID usages remain on UUID.randomUUID(), which is appropriate.
• Conditional checks/error handling: No new special checks or error-swallowing paths are introduced.
• Tests/results: No new unit test is included for the utility bit layout, but the implementation is straightforward and existing CheckStyle passes. I ran mvn checkstyle:check -pl fe-foundation,fe-core -am -DskipTests -Dskip.doc=true successfully and git diff --check successfully.
• Observability: Query-id logging and audit behavior are unchanged except for the generation source.
• Transaction/persistence/data writes: No transaction, persistence, or data-write path semantics are changed.
• Performance: The change removes the identified synchronized SecureRandom contention from these query-id paths without adding meaningful overhead.

Existing review context: I did not re-raise the already discussed UUIDUtils placement comment. The provided focus file had no additional focus points.