Archivos para la categoría ‘Problemas Frecuentes’

Las excepciones de tipo NullPointer son las causas de excepción en tiempo de ejecución más comunes.

Todos los valores en Java, excepto las primitivas, son referencias a objetos y todos tienen un valor por defecto, el valor null, que indica que el objeto no tiene asignado ningún valor. A un objeto con valor null, no inicializado, que no referencia ningún objeto, no se le puede aplicar ningún método, siendo el resultado el lanzamiento de una excepción de tipo NullPointerException

Una excepción de tipo NullPointerException lleva asociada la información de la línea de código donde se produjo el error. El mecanismo para detectar y corregir el error es directamente ir a esta línea de código y averiguar cuál de los objetos involucrados en la operación es el que no ha sido inicializado. Una vez detectado, será necesario inicializar el valor del objeto, pero siempre teniendo cuidado de no hacerlo para simplemente eliminar el error, sino que se le debe asignar un valor acorde con la lógica propia del programa.

class Casa{
private long precio;
 
public Casa (long precio){
this.precio = precio;
}
 
public long getPrecio(){
return precio;
}
 
public class Vender {
 
private Casa casa;
 
public static void main(String[] args){
 
Vender vender = new Vender();
System.out.println(vender.casa.getPrecio());
}
}

Obviamente al ejecutar este ejemplo, se producirá un error indicando la línea concreta del error, y revisando esta línea se puede ver que la casa no está inicializada, y al no tener una referencia de la misma no se puede operar sobre el objeto y se lanzará la excepción NullPointerException.

Por ejemplo, el error se podría corregir inicializando el objeto casa incluido en el objeto Vender.

private Casa casa = new Casa(100000);

En Java, hay varios parámetros para controlar el tamaño inicial y el tamaño máximo que puede tomar la máquina virtual.

Además, hay que tener en cuenta el tipo de memoria sobre el que se quiere actuar: heap, non-heap (PermGen). Los valores por defecto que se dan corresponden a máquina virtuales de Sun, y son orientativos, porque pueden cambiar entre versiones de la máquina virtual. Los parámetros son los siguientes, fijándose a 128Mb.

• -Xms128m: Tamaño de inicio de la máquina virtual de Java a 128Mb. El valor por defecto son 64Mb. Si se aumenta este valor, se elimina el tiempo que se tardaría en aumentar el tamaño en memoria de la máquina virtual si se llegara el caso de que se necesitara más memoria, por lo que aumentaría el rendimiento en los casos que la aplicación haga uso intensivo de la memoria.
• -Xmx128m: Tamaño máximo de la máquina virtual de Java a 128Mb.  El valor por defecto son 128Mb. Si la aplicación supera el tamaño máximo de memoria que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError.  No conviene asignar a este parámetro el máximo de la memoria de la máquina porque si ya no queda memoria física disponible (por la que usa el sistema operativo u otras aplicaciones) se pueden producir escrituras en memoria asignada a otros programas y provocar un auténtico lío.
• -XX:PermSize=128m: Tamaño de inicio de la memoria de tipo PermGen a 128Mb. Arrancar la máquina virtual con un valor superior al por defecto agiliza la carga de aplicaciones, sobre todo en el caso de aplicaciones que hagan uso intensivo de este tipo de memoria (Spring, Hibernate…)
• -XX:MaxPermSize=128m: Tamaño máximo de la memoria de tipo PermGen a 128Mb. El valor por defecto son 64Mb. Si la aplicación supera el tamaño máximo de memoria para este tipo que marca este parámetro, se lanza la excepción java.lang.OutOfMemoryError: PermGen space. El valor necesario para este parámetro siempre suele ser menor que el de la memoria de tipo heap.

Si se quiere especificar un valor distinto de 128Mb, que se utiliza para todos los parámetros como ejemplo para simplificar, bastaría con sustituir el valor 128 del parámetro con el que se desee, siempre que sean múltiplos de 2 (64, 128, 256, 512, 768, 1024, 2048…)

Conocidos los tipos de memoria y los parámetros que los controlan, ahora viene la pregunta, ¿cómo especifico estos valores para mi aplicación? La respuesta es la misma para todos los casos: Los valores se especifican como parámetros en el arranque de la máquina virtual que ejecutará la aplicación. La diferencia estribará en cómo se arranca la aplicación: con un script, desde línea de comandos, mediante ant…

A continuación se dan distintos ejemplos de modificación de la memoria de distinta forma. No es necesario especificar todos los parámetros, se pueden especificar todos o ninguno (y se tomarían los valores por defecto)

Línea de comandos

• Ejecución de un jar: java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m  -jar example.jar
• Ejecución de una clase: java -Xms128m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m  com.programacionenjava.examples.MemoryExample

Ant

<java classname=»com.programacionenjava.examples.MemoryExample» fork=»yes» spawn=»true»>
<jvmarg value=»-Xms128m»/>
<jvmarg value=»-Xmx512m»/>
<jvmarg value=»-XX:PermSize=128m»/>
<jvmarg value=»-XX:MaxPermSize=128m»/>
<classpath refid=»execution.classpath»/>
</java>

Script

Si el arranque de la máquina virtual se produce en un script, hay que editar el script y añadir estos parámetros en la sentencia de arranque. El siguiente ejemplo muestra cómo añadir estos parámetros en el script de arranque de un Tomcat.

• En Windows: set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m
• En Linux: JAVA_OPTS=»$JAVA_OPTS -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256m»

Por último, recordamos que resolver el problema de una excepción de tipo java.lang.OutOfMemoryError simplemente aumentando el tamaño de la memoria virtual puede retrasar el problema pero no evitarlo si el problema es una fuga de memoria. Puedes encontrar más información aquí.

Durante el arranque de Tomcat, cuando la aplicación web lleva asociada una conexión a una base de datos, uno se puede encontrar un error con el siguiente mensaje

Cannot create JDBC driver of class » for connect URL ‘null’

Si aparece este mensaje, no se ha iniciado la conexión a la base de datos y, por lo tanto la aplicación no funciona.

Este error se puede dar cuando se realiza un cambio de versión, de un Tomcat 4.1.27/5.0.x a un Tomcat 5.5.x/6.0.x y no se tiene cuidado en adecuar las aplicaciones web a la nueva versión.

El problema viene del cambio de estructura del xml de configuración de los contextos, context.xml. Concretamente, el elemento Resource pasa de definirse en 2 elementos, Resource y ResourceParams, a uno solo, Resource, dónde los parámetros son atributos de este único elemento. A continuación se puede ver la diferencia entre las dos configuraciones para una conexión a una base de datos en postgres

Tomcat 4.1.27/5.0.x

	<Resource
        name="jdbc/BaseDeDatosPool"
        auth="Container"
        type="javax.sql.DataSource"
    />
    <ResourceParams name="jdbc/BaseDeDatosPool">
        <parameter>
            <name>driverClassName</name>
            <value>org.postgresql.Driver</value>
        </parameter>
        <parameter>
            <name>url</name>
            <value>jdbc:postgresql://127.0.0.1/mibasededatos</value>
        </parameter>
        <parameter>
            <name>username</name>
            <value>postgres</value>
        </parameter>
        <parameter>
            <name>password</name>
            <value></value>
        </parameter>
        <parameter>
            <name>maxActive</name>
            <value>20</value>
        </parameter>
    </ResourceParams>

Tomcat 5.5.X/6.0.x

<Resource name="jdbc/BaseDeDatosPool" auth="Container"
	type="javax.sql.DataSource" driverClassName="org.postgresql.Driver"
	url="jdbc:postgresql://127.0.0.1/mibasededatos"
	username="postgres" password="" maxActive="20"/>

Tomcat, al parsear el xml para inicializar el recurso, encuentra un error en el context.xml y la cadena de error que proporciona es Cannot create JDBC driver of class » for connect URL ‘null’, que en un principio puede despistar porque no resulta claro. Basta con adecuar el xml de configuración a la versión de Tomcat que se está utilizando para que deje de producirse.

El error se produce cuando el context.xml está malformado en la definición de recursos, por lo que se puede producir por otras causas diferentes de una cambio de versión, pero he centrado esta entrada en esta causa porque suele ser la más común

La memoria de la Máquina Virtual se divide en varias regiones. Una de estas regiones es el PermGen, el área de memoria utilizada para, entre otras cosas, guardar el metadata de las clases como los atributos y sus tipos de datos, métodos etc. Esta memoria es de tipo non-heap. Las instancias de las clases se cargan en la memoria de tipo heap, a la que se van añadiendo y eliminando las instancias de las clases según se van utilizando y eliminándose por el recolector de basura (Garbage Collector, en adelante GC).

No vamos a entrar en el mecanismo de la carga y eliminación de clases en java porque excede este artículo, pero sí lo comentaremos brevemente para poder entender el porqué de la excepción OutOfMemoryException: para que una clase pueda ser eliminada por el recolector de basura (GC), es necesario que no esté referenciada por ninguna otra clase. Para que se pueda eliminar la memoria ocupada por una clase en el espacio PermGen, es necesario además que se elimine el classloader que cargó la clase.

El valor por defecto del espacio PermGen es de 64 Mb en la máquina virtual (VM) de Sun. Este valor es suficiente normalmente para las aplicaciones que corren de forma independiente. En el caso de una aplicación que corra en un servidor web tipo Tomcat o un servidor de aplicaciones, hay casos en los que este valor no es suficiente.

En primer lugar, es posible que la aplicación necesite más espacio por su propia arquitectura. Las librerías Spring e Hibernate son librerías grandes, que cargan muchas clases y además hacen uso de proxies y carga dinámica de clases que hacen uso del espacio PermGen por lo que puede que los 64Mb no sean suficientes. Este caso se da cuando la excepción con el error se produce nada mas arrancar el servidor web o de aplicaciones o al acceder a la aplicación. Para solventar este problema bastará con aumentar el tamaño máximo de la memoria de tipo PermGen según veremos más adelante.

En segundo lugar, la causa más probable de una excepción java.lang.OutOfMemoryError: PermGen space failure se produce cuando la aplicación se reinstala en el servidor sin reiniciar el servidor. La forma de reinstalar las aplicaciones es eliminando el classloader que cargó la aplicación por primera vez y creando un nuevo classloader para la nueva instancia de la aplicación. En teoría, esto proporciona una forma limpia de reinstalar aplicaciones, pero si el servidor web o de aplicaciones guarda una referencia al classloader antiguo, se produce una fuga de memoria (memory leak) y el resultado es que tendremos las clases de la aplicación cargadas dos veces en memoria. Es cuestión del número de recargas y de la memoria gastada por la aplicación el que se produzca la excepción  java.lang.OutOfMemoryError: PermGen space failure. En este caso no basta con aumentar el tamaño máximo de la memoria, ya que esto sólo retrasaría el problema a unas cuantas reinstalaciones más. En este caso la única solución consiste en averiguar la causa de la fuga de memoria. Esto también excede el contenido de este artículo, aunque lo intentarmos tratar con profundidad en otra ocasión. Por el momento sólo proporcionamos un enlace muy interesante, aunque en inglés, acerca de posibles causas de fugas de memoria en java: http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669

Por último, a continuación incluimos el argumento que es necesario incluir al arrancar la máquina virtual para especificar el tamaño de esta región PermGen en Mb, XX:MaxPermSize=128m para el tamaño máximo y XX:PermSize=128m para que la máquina virtual ya arranque con este tamaño y no tenga que reservar más espacio en tiempo de ejecución.