我有一个单例ServerConfigs，其中包含（url，端口，连接数，...）的static ConcurrentHashMap成员。ServerConfig
单例有两个 'getServer' 方法：
1）返回单个服务器配置
2）返回整个地图
单例还通过在每次调用 getServer 方法时迭代一个整数（ServerConfig 的成员）来跟踪每个服务器附加到它的连接数来管理这些配置。它还公开了一个 releaseFor(ServerConfig) （可以是 ID，不一定是 obj 本身）和 releaseAll() 方法来减少映射中的连接计数。
我有一个Worker接口，其抽象 impl通过向其提交 s（基于 getServer 方法构造）来利用 a ThreadPoolExecutor（包含在另一个单例类 [ ThreadPool] 中并在应用程序中共享）。CallableClient抽象的 Worker 将被许多表示各种工作类型的 impl 扩展。单个会话将有许多 Worker impls 实例将任务提交给ThreadPool持有ThreadPoolExecutor.
A）我对使用单例的指令很满意。
B) 是的，这种方法本质上是有缺陷的，因为使用此代码的单个应用程序实例只会获得与 ServerConfig 端点的实际连接数的短视，因为该应用程序的其他应用程序实例和其他应用程序正在访问它们。端点不是 JMX 友好的。
我需要一些帮助来确定是否：
1）这ConcurrentHashMap是正确的选择，ServerConfigs因为多个线程可能正在访问它以进行读取和写入
2）公开映射的方法是否应该同步？
3) 持有与此处表示的端点的连接数的 ServerConfig 成员是否应该是除 int 之外的另一种类型？它的 getter/setter 是否应该同步？
4）返回与地图分离的深层副本ServerConfig是否会更好，因为它们的管理无论如何都集中在 ServerConfigs 单例中？
此外，将有一个 ScheduledThreadPoolExecutor 用于每隔几分钟监视服务器以更新 ServerConfigs 映射 - 其他几个线程访问和更新映射。