2011-03-28 13 views
9

Esto se refiere a Java String Constant Pool. En uno de mis Programas, estoy descifrando la contraseña de la base de datos y la estoy almacenando en un String. Escuché que Java Strings se almacenará en un grupo de constantes y no se destruirán los reinicios de la VM o el ClassLoader que cargó los Strings Quits.Con respecto a Java String Constant Pool

Si es así, mis contraseñas se almacenarán en el grupo de cadenas. Estoy muy preocupado por este problema. ¿Hay alguna otra forma de destruir estos literales o cualquier otra cosa que pueda hacer?

Para sugerir en este,

Saludos, Sunny.

Respuesta

6

Hay varios problemas diferentes en juego aquí. En primer lugar, el término "grupo constante" se refiere a una parte muy específica de los archivos de clase para literales numéricos y de cadena, o a las estructuras de datos generadas a partir de esta parte de los archivos de clase que residen en la JVM. La contraseña no se almacenará aquí a menos que sean parte de los archivos de la clase.

Sin embargo, algunos objetos String son de hecho almacenados y compartidos durante todo el programa a través de la interna de String. Cualquier literal de cadena se interna automáticamente, al igual que cualquier cadena en la que invoque el método de intern(). Sin embargo, a mi leal saber y entender, no hay otras cadenas almacenadas de esta forma, así que a menos que automáticamente internes las cadenas con tus propias contraseñas, no creo que debas preocuparte por esto.

Otro problema que debe tenerse en cuenta es que si no desea que las contraseñas residan en la memoria, deberá tener cuidado con la recolección de basura ya que una Cadena a la que ya no se hace referencia podría estar en la memoria. De manera similar, si usa ciertos métodos de cadenas como subcadenas que comparten representaciones de respaldo entre cadenas, puede conservar la cadena de contraseña completa después de que haya terminado de usarla.

Si lo que le preocupa es que otro código Java sea capaz de ver contraseñas antiguas que han sido internados o que todavía viven en la memoria, no necesita preocuparse. No hay forma de iterar o mirar los elementos del grupo de cadenas internas o de abrir una cadena para ver su matriz de respaldo.

+1

Puede que no sea fácil encontrar esas cadenas del código, pero estarán en un volcado dinámico.Si estuviera tratando de llegar a ellos, trataría de disparar un heapdump y tratar de separar el archivo de volcado. – Ryan

3

Esto solo se aplica a los literales de cadenas y cadenas a los que ha llamado el método intern(). Piénselo: si se aplicara a todas las cadenas, se quedaría rápidamente sin memoria en, por ejemplo, una aplicación de servlet que maneja parámetros de solicitud con diferentes valores (String).

+0

Java 1.8.20 introdujo una función de deduplicación de cadenas de fondo que es muy similar a tener su interno de cadenas() 'd sin que nadie llame al interno() ... – Ryan

+0

Dado que las cadenas llaman 'pasante()', todavía están Sujeto a la recolección de basura ordinaria, no hay ninguna razón por la cual el tratamiento de todas las cadenas, como si 'intern()' se aplicara después de la construcción, debería elevar los requisitos de memoria. En realidad, habrá * menos * instancias de cadena en el montón entonces. Sin embargo, hacerlo sería un desastre de rendimiento ... – Holger

-1

Amigo, use un búfer de cadena para obtener la contraseña y realizar (presumiblemente) operaciones de tipo cadena.

StringBuffer almacena cadenas como char [], que puede eliminar. O anulado o qué tienes tú. Di StringBuffer.delete(0,StringBuffer.length());

o simplemente obtener la contraseña db como un char [] y trabajar directamente en eso - pero creo que la forma StringBuffer (suponiendo que usted ha hecho todo el código usando métodos String) será un salto más fácil.

+0

Un char [] es genial si controlas la interfaz. Si tiene que llamar a un método que toma una contraseña como String tarde o temprano, se creará un objeto String ... – Ryan

Cuestiones relacionadas