archivos JAR, ¿acaso no solo inflan y ralentizan Java?

Question

Bien, la pregunta puede parecer tonta, pero lo estoy preguntando de todos modos.

Después de luchar durante horas para poner en marcha un proyecto Spring + BlazeDS, descubrí que estaba teniendo problemas con mi proyecto como resultado de no incluir las dependencias adecuadas para Spring, etc. Faltaban .jars de mi WEB -INF/lib carpeta, sí, tonto yo.

Después de un tiempo, logré obtener todos los archivos .jar a donde pertenecen, y llega a la friolera de 12.5MB, y hay más de de ellos! Lo cual me preocupa, pero probablemente y con suerte no debería preocuparme.

¿Cómo funciona Java en términos de estos archivos JAR, ocupan bastante espacio en el disco duro, teniendo en cuenta que es un código fuente comprimido y compilado. Entonces eso realmente puede llenar rápidamente mucha RAM y en un instante.

Mis preguntas son: cargar

¿El Java un archivo .jar entera en la memoria cuando decir, por ejemplo, una clase en la que se crea una instancia .jar? ¿Qué hay de las cosas que están en el .jar que nunca se usan?

¿Los .jars se almacenan en caché de alguna manera, para optimizar el rendimiento de la aplicación?

Cuando se carga un solo .jar, entiendo que la cosa se encuentra en la memoria y está disponible en varias solicitudes HTTP (es decir, durante la vida de la instancia del servidor en ejecución), a diferencia de PHP donde los objetos se crean sobre la marcha solicitud, ¿es correcta esta suposición?

Al usar Spring, estoy pensando, tenía que incluir todos esos frágiles .jars, ¿no sería mejor usar Java nativo, con al menos una solución ORM como Hibernate?

Hasta ahora, Spring simplemente tomó más tiempo configurando, espacio extra en el disco duro, memoria extra, consumo de CPU, así que estoy preocupado de que el framework cueste demasiado rendimiento de la aplicación solo para obtener, por ejemplo, IoC implementado con mi servidor BlazeDS.

Todavía tiene que venir ORM, un marco de prueba de unidades y partes y piezas aquí y allá. Es tan fácil hinchar un proyecto de manera rápida e irresponsable.

¿Dónde hago el trazo?

Answer 1

"no Java cargar todo un archivo .jar en la memoria cuando dicen, por ejemplo, se crea una instancia de una clase en que .jar? ¿Qué pasa con las cosas que hay en la .jar que nunca se utiliza. "

No, el cargador de clases carga cada archivo .class que sea necesario.

" No .jars conseguir algún modo en caché , por optimizado rendimiento de las aplicaciones "

JAR son como DLL (a excepción de los detalles acerca de la vinculación frente a la carga de clases):?. son sólo las bibliotecas comprimidas de los archivos .class no se almacenan en caché: .class archivos ar e cargado en el espacio permanente según sea necesario.

"Cuando se carga una sola .jar, I entender que lo sienta en memoria y está disponible a través de múltiples peticiones HTTP (es decir, para la tiempo de vida de la instancia del servidor correr), a diferencia de PHP donde los objetos son creados sobre la marcha con cada solicitud, ¿es correcta esta suposición? "

Cuando su servidor de aplicaciones carga una clase en el espacio permanente, está disponible mientras el servidor esté funcionando.

"Al utilizar la primavera, estoy pensando, me tenía que incluir todos esos .jars complicados, no habría acabo de ser mejor simplemente usando nativa de Java, con decir que al menos y la solución ORM como Hibernate? "

No si crees que usar Spring te está comprando algo. Si no cree que el análisis de costo/beneficio lo favorece, no use Spring. Pero no parece que esté haciendo un buen análisis si las dependencias lo están desanimando.

"Hasta ahora, la primavera acaba de tomar el tiempo extra de configuración , espacio adicional en el disco duro, memoria adicional, el consumo de CPU, así que estoy preocupa que el marco va a costar demasiado aplicación rendimiento justo para obtener, por ejemplo, IoC implementado con mi servidor BlazeDS ".

No tiene idea de cuál es la penalidad de rendimiento para usar Spring. Mídelo si crees que es un problema. Mi apuesta es que el código de la aplicación o el esquema de la base de datos será el mayor problema.

"Todavía tiene que venir ORM, un marco de pruebas de unidad y partes y piezas aquí y allá. Es tan fácil de la hinchazón en marcha un proyecto de forma rápida y fácil irresponsable."

¿Por qué irresponsablemente?

"¿Dónde hago el trazo?"

Por supuesto, escribir el suyo propio. Hacerlo todo desde cero. Vas a tener una mejor idea de lo que está comprando un marco para usted y cuáles son los costos reales son cuando haya terminado.

Agregaré esto: la gente de Spring escribe algunos de los mejores códigos que existen. Mejor que cualquier cosa que usted o yo escribamos. Elije cualquier marco porque cree que obtendrá un impulso del uso del código que ha sido rigurosamente diseñado, tiene un público más amplio, ha sido probado más a fondo, y es mejor por prácticamente todas las medidas que usted mismo. No dejaría que la gran cantidad de dependencias me impida usarla. en un servidor de aplicaciones y asigna 256 MB de RAM a esa JVM, certifico No me importa mucho si el espacio permanente consume el 10% de ese total, hasta que mida que es un problema.

Creo que lo que realmente está pasando es que preferirías escribir PHP en lugar de Java. Es una idea justa, porque mucha gente piensa que el uso de lenguajes dinámicos puede ofrecer valor sobre Java. La mayoría de los sitios todavía están escritos en PHP, por lo que su escepticismo está justificado.

Recomendaría crear prototipos de un caso de uso o dos con y sin Spring y usando PHP. Tendrás una mejor idea de lo que funciona para ti después de eso.

Answer 2

El cargador de clases solo debe cargar las clases que necesita y permanece residente en la memoria. No te preocupes por 12 MB. RAM es barato. Los objetos que cree (en una aplicación grande) usarán mucha más memoria que las clases que se cargan.

Así que, en resumen, no se preocupe. :)

No es un buen artículo sobre IBM developerWorks con el título "Desmitificando los problemas de carga de clases, Parte 1: Introducción a la carga de clases y herramientas de depuración"

punto adicional - Cuando se llega a los costos, El Tiempo de desarrollador cuesta mucho más que el hardware, por lo que si Spring/Hibernate/WhateverTool lo ayuda a desarrollar la aplicación más rápido y más fácil, vale la pena el costo de la memoria RAM que se esté utilizando.

Answer 3

Para algunas de estas preguntas, probablemente sea mejor que busque el código fuente en java.util.jar. Los archivos JAR se tratan como un tipo de archivo ZIP (lo cual tiene sentido ya que los archivos JAR son básicamente archivos ZIP con un archivo de manifiesto), por lo que el archivo completo no se carga a la vez.

Answer 4

Si tiene problemas con la administración de dependencias, una herramienta como Maven o Ivy puede ayudar, aunque vienen con sus propias curvas de aprendizaje. Ambos le permiten especificar las dependencias directas y dejar que la herramienta calcule y resuelva las dependencias transitivas.

Answer 5

Aunque el cargador de clases carga clases bajo demanda, los metadatos JAR probablemente serán cargados por el cargador de clases ya que deberían tener información sobre los nombres de clase completamente clasificados que son parte del JAR (requisitos de espacio menores). Cuando el cargador de clases requerido puede cargar rápidamente la clase desde esta información.

Agregando más JAR probablemente tener pocos KB (<) de espacio adicional (información JAR), pero no en realidad aumentar su PermGenSpace menos que no se requiere la clase (requerido directa o indirectamente)

por lo que son seguros para agregar bibliotecas adicionales siempre que no refiera/cargue todas las clases innecesarias (a través del uso: directa o indirectamente, incluida la ejecución de código estático en las clases).

También PermGenSpace está aislado de la memoria Heap (en términos de asignación de memoria física) aunque funcionan juntos.