java - Design decisions for singleton services managing ConcurrentHashMap of server endpoint configs -

i have singleton serverconfigs contains static concurrenthashmap member of serverconfig (url, port, number of connections, ...).

the singleton has 2 'getserver' methods:
1) returns single server configuration
2) returns whole map

the singleton manages these configurations keeping track of number of connections each server has attached by iterating integer (member of serverconfig) every time getserver methods called. exposes releasefor(serverconfig) (can id, not obj itself) , releaseall() methods decrement connection counts in map.

i have worker interface abstract impl utilizes threadpoolexecutor (that contained in singleton class [threadpool] , shared across app) submitting callableclients (which constructed based on getserver methods). abstract worker extended many impls represent various work types of work. single session have many instances of worker impls submitting tasks central threadpool wrapper holding threadpoolexecutor.

a) i'm @ peace directive use singletons.
b) yes, approach inherently flawed since single app instance using code myopic view of actual number of connections serverconfig endpoints, since there other app instances of app , other apps accessing them. endpoints not jmx friendly.

i need in determining if:
1) concurrenthashmap correct choice hold serverconfigs due fact several threads may accessing both reads , writes
2) should methods expose map synchronized?
3) should serverconfig member holding number of connections endpoint represented here type int? should getter/setters synchronized?
4) returning deep copies of serverconfig separated map better idea, since management centralized serverconfigs singleton anyway?

furthermore, there scheduledthreadpoolexecutor used monitor servers every few minutes update serverconfigs map - few threads accessing , updating map.