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