fix(naming): fix check-then-act race conditions on ConcurrentHashMap in naming module

[daguimu]

Problem

Four methods in the naming module use containsKey() followed by get() on ConcurrentHashMap/ConcurrentMap fields. Although each method is individually thread-safe, the compound operation is not atomic, creating a check-then-act race condition that can cause NullPointerException.

Race Condition Explained

Take ServiceManager.removeSingleton() as an example:

// Before (buggy)
if (namespaceSingletonMaps.containsKey(service.getNamespace())) {       // Step 1: check
    namespaceSingletonMaps.get(service.getNamespace()).remove(service);  // Step 2: get and use
}

Between Step 1 and Step 2, another thread may remove the entry:

Thread A: containsKey("public") -> true
                                          Thread B: namespaceSingletonMaps.remove("public")
Thread A: get("public") -> null
Thread A: null.remove(service) -> NullPointerException!

ConcurrentHashMap guarantees thread-safety for individual operations, but NOT for compound operations spanning two separate method calls.

Fix

Replace all containsKey() + get() patterns with a single get() call and null check:

// After (safe)
Set<Service> services = namespaceSingletonMaps.get(service.getNamespace());  // single lookup
if (services != null) {                                                       // null check
    services.remove(service);                                                 // safe
}

All 4 Fix Points

Class	Method	Field Type
ClientServiceIndexesManager	removePublisherIndexesByEmptyService	ConcurrentMap<Service, Set<String>>
NamingMetadataManager	containInstanceMetadata	ConcurrentMap<Service, ConcurrentMap<String, InstanceMetadata>>
NamingFuzzyWatchContextService	removeFuzzyWatchContext	ConcurrentMap<String, Set<String>>
ServiceManager	removeSingleton	ConcurrentHashMap<String, Set<Service>>

All four fields are modified at runtime by event handlers and background tasks, making the race condition window practical.

Tests

All existing tests pass (31 tests across ClientServiceIndexesManagerTest, NamingMetadataManagerTest, NamingFuzzyWatchContextServiceTest). The fix is behavior-preserving under non-concurrent conditions - it only prevents NPE when concurrent map modifications occur.

Impact

Prevents potential NPE in naming service operations (service registration, metadata lookup, fuzzy watch, service removal). No behavioral change under normal single-threaded access.

[github-actions]

Thanks for your this PR. 🙏
Please check again for your PR changes whether contains any usage/api/configuration change such as Add new API , Add new configuration, Change default value of configuration.
If so, please add or update documents(markdown type) in docs/next/ for repository nacos-group/nacos-group.github.io

---

感谢您提交的PR。 🙏
请再次查看您的PR内容，确认是否包含任何使用方式/API/配置参数的变更，如：新增API、新增配置参数、修改默认配置等操作。
如果是，请确保在提交之前，在仓库nacos-group/nacos-group.github.io中的docs/next/目录下添加或更新文档（markdown格式）。

[codecov-commenter]

Codecov Report

❌ Patch coverage is 60.00000% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...m/alibaba/nacos/naming/core/v2/ServiceManager.java	66.66%	0 Missing and 1 partial ⚠️
...ing/core/v2/index/ClientServiceIndexesManager.java	50.00%	0 Missing and 1 partial ⚠️
.../core/v2/index/NamingFuzzyWatchContextService.java	66.66%	0 Missing and 1 partial ⚠️
...naming/core/v2/metadata/NamingMetadataManager.java	50.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!