Quiero saber cuántas instancias de una clase miembro estática puede crear la clase adjunta. Supongo que solo uno, pero el siguiente extracto de Bloch no tiene sentido para mí.

Citando el Java efectivo de Joshua Bloch - Elemento 22 *: favorece las clases de miembros estáticos sobre los no estáticos.

Un uso común de las clases de miembros estáticos privados es representar los componentes del objeto representado por su clase adjunta. Por ejemplo, considere una instancia de Map, que asocia claves con valores. Muchas implementaciones de mapas tienen un objeto de entrada interno para cada par clave-valor en el mapa. Si bien cada entrada está asociada a un mapa, los métodos en una entrada (getKey, getValue y setValue) no necesitan acceso al mapa. Por lo tanto, sería un desperdicio usar una clase de miembro no estático para representar entradas: una clase de miembro estático privado es lo mejor. Si omite accidentalmente el modificador estático en la declaración de entrada, el mapa seguirá funcionando, pero cada entrada contendrá una referencia superflua al mapa, lo que desperdicia espacio y tiempo.

Afirma que el mapa crea un objeto de entrada para cada par clave-valor en el mapa, es decir, varias instancias de la clase de miembro estático.

¡Entonces mi suposición está mal! Eso significa que mi comprensión de las clases miembro estáticas es incorrecta. Todos saben cómo se comporta una variable miembro estática, la clásica cadena final estática, por ejemplo: solo hay una instancia del objeto.

¿Significa esto entonces que una clase de miembro estático no se instancia en realidad cuando se instancia el objeto que lo encierra?

Bueno, en ese caso, ¿qué sentido tiene Map usando una clase de miembro estático para Entry? ¿Por qué no solo usar una interfaz en la API? Cualquier otra clase de Colecciones podría proporcionar su propia implementación.

[*] Me acabo de dar cuenta de que es el ítem 18 en la versión PDF del libro que tengo