vi java mapa hash, el método claro, como este:
no podía comprender la aplicación de un método claro de HashMap en Java
public void clear() {
modCount++;
Entry[] tab = table;
for (int i = 0; i < tab.length; i++)
tab[i] = null;
size = 0;
}
No entiendo, ¿por qué tomar una nueva pestaña para borrar.
¿Por qué no utilizar la tabla para borrar?
No entiendo, por qué una nueva pestaña para borrar.
No es una tabla nueva ... es solo una variable local.
me ocurren tres posibles razones:
legibilidad, según lo sugerido por @Bhesh Gurung ... a pesar de que casi no hace una diferencia aquí (OMI).
Podría mitigar (algo) el daño causado si un hilo llama a clear(), mientras que un segundo hilo realiza una actualización que podría hacer que la tabla se expanda. Pero ciertamente no soluciona el problema, por lo que me inclinaría a descartar esto como una falta de sentido.
Podría mejorar el rendimiento; p.ej. dado que el optimizador sabe que la referencia en la variable local tab no puede cambiar, puede optimizar mejor los límites de la matriz.
De estos, creo que la tercera razón es la más plausible.
(no creo que es algo que ver con el modificador transient. En este caso, el modificador es sólo allí para facilitar la lectura. La clase HashMap ofrece readObject y writeObject que hace que el discutible transient modificador.)
Puede ser porque el campo table está declarado como transient, por lo que no forma parte del estado persistente del objeto HashMap. El campo table se reemplaza en métodos como resize(), que no está sincronizado, por lo que es posible hacer que el campo table se intercambie debajo de usted al iterar a través de todas sus entradas dentro de una llamada a un método clear(). Si hace referencia a table primero, y repite esa referencia, tenemos la garantía de que si cambia el campo table, todavía estamos iterando a través del table original.
Pero, de nuevo, un 'HashMap' no es seguro para subprocesos en operaciones" normales ", entonces ¿por qué le importaría en' clear() '? –
@JoachimSauer Si agrega más entradas en un hilo, llama a 'resize()', justo después de que otro hilo llame a 'clear()'. Hacer esto asegura que la llamada 'clear()' establece todas las entradas antiguas en nulo, mientras que la nueva 'tabla' se está creando. De lo contrario, en el peor de los casos, podría terminar con un HashMap de todos los nulos a excepción de la entrada que acabo de agregar. –
Entiendo qué buena seguridad de hilo sería. Pero lo que estoy diciendo: 'put' solo no es seguro para subprocesos (pueden suceder cosas desagradables si lo llaman varios hilos). Entonces, ¿por qué les importaría si otro método es seguro para subprocesos? –
Probablemente por legibilidad. –