Pregunta Java: wait() fuera de synchronized

Piensa la respuesta antes de abrirla. Todas las opciones parecen razonables, y casi siempre hay un detalle que lo cambia todo.

Pregunta Java · Threads

¿Cuál es el resultado de compilar y ejecutar el siguiente código? ¿Y por qué?

public class Prueba {
    public static void main(String[] args) {
        String mensaje = "Saludos";
        try {
            mensaje.wait();
        } catch (InterruptedException e) {
        }
        System.out.println("mensaje: " + mensaje);
    }
}
  1. La compilación falla.
  2. Se lanza una IllegalMonitorStateException en tiempo de ejecución.
  3. No se imprime nada, espera indefinidamente.
  4. Se imprime "mensaje: Saludos"
Ver la respuesta

Respuesta: 2.

java PruebaException in thread "main" java.lang.IllegalMonitorStateException: current thread is not owner
	at java.base/java.lang.Object.wait0(Native Method)
	at java.base/java.lang.Object.wait(Object.java:389)
	at java.base/java.lang.Object.wait(Object.java:351)
	at Prueba.main(Prueba.java:5)

wait() hace que el hilo espere hasta que otro llame a notify() o notifyAll() sobre el mismo objeto, y solo se puede llamar teniendo su monitor, es decir, dentro de un synchronized (mensaje) {…}. Aquí no hay ningún bloque synchronized, así que compila pero falla al ejecutar.

Es la hermana de otra pregunta en la que sí hay synchronized, pero sobre el objeto equivocado. Hoy rara vez se usan wait y notify directamente: java.util.concurrent tiene herramientas más seguras, como CountDownLatch o las colas bloqueantes.

Pregunta publicada en 2013 y revisada en octubre de 2026. La respuesta se comprobó compilando y ejecutando el código con Java 25 LTS en un contenedor limpio; las salidas están copiadas de esa ejecución.

Pregunta Java: dos hilos y una variable compartida

Piensa la respuesta antes de abrirla. Todas las opciones parecen razonables, y casi siempre hay un detalle que lo cambia todo.

Pregunta Java · Threads

¿Cuál es el resultado de ejecutar el siguiente código? ¿Y por qué?

public class Prueba extends Thread {
    static String cadena = "hola";
    public static void main(String argv[]) {
        Prueba t = new Prueba();
        t.inicia(cadena);
        System.out.println(cadena);
    }
    public void inicia(String aux) {
        cadena = aux + " mundo ";
        start();
    }
    public void run() {
        for (int i=0; i<4; i++) { cadena = cadena + " " + i; }
    }
}
  1. imprime "hola mundo"
  2. imprime "hola mundo 0 1 2 3"
  3. El resultado es impredecible.
Ver la respuesta

Respuesta: 3.

300 ejecuciones, contadas con uniq -c300 hola mundo

inicia() cambia la cadena a "hola mundo " y arranca un hilo nuevo; el hilo principal sigue y hace el println sin esperar a que el otro termine. Los dos hilos usan la misma variable estática sin ninguna sincronización, así que nada garantiza qué parte del bucle habrá hecho el segundo hilo cuando el primero imprima, ni siquiera que vea sus cambios.

¿Y la salida? En 300 ejecuciones salió siempre hola mundo : arrancar un hilo tarda bastante más que llegar al println. Pero eso es una casualidad del momento, no una garantía, y con otra máquina o con el sistema cargado podría salir otra cosa. Precisamente por eso la respuesta correcta es la 3: que un error de concurrencia no aparezca en las pruebas no significa que no exista. Para esperar al hilo se usa t.join() antes de imprimir.

Pregunta publicada en 2013 y revisada en octubre de 2026. La respuesta se comprobó compilando y ejecutando el código con Java 25 LTS en un contenedor limpio; las salidas están copiadas de esa ejecución.

Pregunta Java: start() con un argumento

Piensa la respuesta antes de abrirla. Todas las opciones parecen razonables, y casi siempre hay un detalle que lo cambia todo.

Pregunta Java · Threads

¿Cuál es el resultado de ejecutar el siguiente código?

public class Prueba extends Thread {
    public void run() {
        System.out.println("método run 1");
    }
    public void run(String s) {
        System.out.println("método run 2");
    }
    public static void main(String[] args) {
        new Prueba().start("hola");
    }
}
  1. imprime "método run 1"
  2. imprime "método run 2"
  3. imprime "hola"
  4. No compila
Ver la respuesta

Respuesta: 4.

javac Prueba.javaPrueba.java:9: error: method start in class Thread cannot be applied to given types;
        new Prueba().start("hola");
                    ^
  required: no arguments
  found:    String
  reason: actual and formal argument lists differ in length
1 error

start() no recibe argumentos, y el compilador lo rechaza. Definir un run(String s) no cambia nada: es una sobrecarga que Thread no conoce. start() arranca un hilo nuevo y la máquina virtual llama en él al run() sin parámetros.

Si se escribe new Prueba().start();, el programa imprime método run 1. Para pasarle datos a un hilo se usa un campo o el constructor, o mejor aún, un Runnable con una lambda.

Pregunta publicada en 2013 y revisada en octubre de 2026. La respuesta se comprobó compilando y ejecutando el código con Java 25 LTS en un contenedor limpio; las salidas están copiadas de esa ejecución.

Lo que no es Java

Texto sobre fondo claro: «Java != javascript».
«Java != javascript»

A pesar del nombre, Java y JavaScript son lenguajes distintos, que solo comparten parte de la sintaxis. JavaScript se llamó así en 1995 por motivos de marketing, aprovechando la fama que Java tenía entonces.

Comparar cadenas en Java: == frente a equals

¿Qué devuelven las seis expresiones de la imagen? Todo se resume en una idea: == compara si dos referencias apuntan al mismo objeto, y equals compara el contenido. Lo que lía es que, con las cadenas, a veces son el mismo objeto sin que lo parezca.

Las respuestas, ejecutadas

Este programa evalúa las seis expresiones de la imagen y unas cuantas más que ayudan a entenderlas:

import java.util.Objects;

void main() {
    String variable = null;

    IO.println("\"cadena\" == \"cadena\"                    -> " + ("cadena" == "cadena"));
    IO.println("\"cadena\" == \"cad\" + \"ena\"               -> " + ("cadena" == "cad" + "ena"));

    String cad = "cad";
    final String cadFinal = "cad";
    IO.println("\"cadena\" == cad + \"ena\"                 -> " + ("cadena" == cad + "ena"));
    IO.println("\"cadena\" == cadFinal + \"ena\"            -> " + ("cadena" == cadFinal + "ena"));

    IO.println("\"cadena\" == \"-cadena\".substring(1)      -> " + ("cadena" == "-cadena".substring(1)));
    IO.println("new String(\"cadena\") == \"cadena\"        -> " + (new String("cadena") == "cadena"));
    IO.println("new String(\"cadena\").equals(\"cadena\")   -> " + new String("cadena").equals("cadena"));
    IO.println("\"-cadena\".substring(1).intern() == \"cadena\" -> " + ("-cadena".substring(1).intern() == "cadena"));

    IO.println("\"cadena\".equals(variable)               -> " + "cadena".equals(variable));
    IO.println("Objects.equals(variable, \"cadena\")      -> " + Objects.equals(variable, "cadena"));
    IO.println("\"Cadena\".equalsIgnoreCase(\"CADENA\")     -> " + "Cadena".equalsIgnoreCase("CADENA"));
    IO.println("\"abeja\".compareTo(\"abeto\")              -> " + "abeja".compareTo("abeto"));

    try {
        IO.println(variable.equals("cadena"));
    } catch (NullPointerException e) {
        IO.println("variable.equals(\"cadena\") -> " + e);
    }
}
javac -g Cadenas.java
java Cadenas
salida"cadena" == "cadena"                    -> true
"cadena" == "cad" + "ena"               -> true
"cadena" == cad + "ena"                 -> false
"cadena" == cadFinal + "ena"            -> true
"cadena" == "-cadena".substring(1)      -> false
new String("cadena") == "cadena"        -> false
new String("cadena").equals("cadena")   -> true
"-cadena".substring(1).intern() == "cadena" -> true
"cadena".equals(variable)               -> false
Objects.equals(variable, "cadena")      -> false
"Cadena".equalsIgnoreCase("CADENA")     -> true
"abeja".compareTo("abeto")              -> -10
variable.equals("cadena") -> java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because "variable" is null
La opción -g guarda los nombres de las variables locales en el .class, y por eso el último mensaje dice "variable". Si lo ejecutas directamente con java Cadenas.java sale "<local1>" en su lugar: el lanzador compila sin esa información.

Por qué cada una da lo que da

ExpresiónResultadoPor qué
"cadena" == "cadena"trueLos literales iguales se guardan una sola vez, en el pool de cadenas. Los dos son el mismo objeto.
"cadena" == "cad" + "ena"trueEs una expresión constante: el compilador une las dos partes y en el .class ya solo está "cadena".
"cadena" == "-cadena".substring(1)falsesubstring crea un objeto nuevo mientras el programa se ejecuta. Mismo texto, otro objeto.
new String("cadena").equals("cadena")trueequals compara los caracteres, que son los mismos.
new String("cadena") == "cadena"falsenew siempre crea un objeto nuevo, distinto del literal.
new String("cadena") == new String("cadena")falseDos new, dos objetos.

Lo interesante está en las dos líneas que añadimos: si una de las partes es una variable normal, la concatenación ocurre al ejecutar y da un objeto nuevo (false). Si la variable es final y se inicializa con un literal, cuenta como constante y el compilador vuelve a unirlas antes de tiempo (true). Es decir, el resultado de == depende de detalles que no se ven al leer el código. Basta un cambio inocente, como quitar un final, para que una comparación que funcionaba deje de hacerlo.

Pasa lo mismo con cualquier texto que llegue de fuera: lo que se lee de un archivo, de la consola o de una petición web son objetos nuevos, aunque contengan exactamente lo mismo que un literal del programa.

La regla: equals, siempre

Para saber si dos cadenas tienen el mismo texto, equals. == solo sirve para preguntar si son el mismo objeto, y eso casi nunca es lo que quieres saber.

intern() devuelve la copia del pool, y por eso "-cadena".substring(1).intern() == "cadena" da true. Es una curiosidad que conviene conocer, pero no una forma de comparar: obliga a acordarse de llamarlo en todas partes.

Cuando la variable puede ser null

Si la variable es null, variable.equals("cadena") lanza un NullPointerException, como se ve en la última línea de la salida. Hay dos formas de evitarlo:

"cadena".equals(variable)

Poner el literal delante: un literal nunca es null, y equals(null) simplemente devuelve false.

Objects.equals(variable, "cadena")

Objects.equals sirve cuando las dos pueden ser null: devuelve true si ambas lo son y nunca lanza la excepción.

Otras comparaciones

Para…Se usaEjemplo
Mismo textoa.equals(b)true / false
Mismo texto, con posibles nullObjects.equals(a, b)true / false
Sin importar mayúsculasa.equalsIgnoreCase(b)"Cadena" y "CADENA" → true
Ordenara.compareTo(b)negativo, cero o positivo: "abeja" va antes que "abeto" → -10

El -10 de compareTo no es una distancia con significado: es la diferencia entre la primera pareja de caracteres que no coinciden (j y t). Lo único que importa es el signo.

Entrada publicada en 2013 y revisada en octubre de 2026. Todo el código se compiló y se ejecutó con Java 25 LTS en un contenedor limpio; las salidas están copiadas de esa ejecución.

No importa

Texto sobre fondo claro: «¡No me importa si funciona en tu máquina! ¡No vamos a enviar tu máquina!», cita atribuida a Vidiu Platon.
¡No importa si funciona en tu máquina! ¡No vamos a enviar tu máquina!

«En mi máquina funciona» es una de las excusas más famosas de la programación. Contenedores como Docker nacieron, en buena parte, para que el entorno del desarrollador y el del servidor sean el mismo y esta frase deje de tener sentido.

Una pequeña lista de los puertos mas conocidos

Estos son algunos de los puertos que quizá debas conocer o con los que debes familiarizarte cuando estás comenzando a desarrollar, algunos no se usan tanto, y desde luego se usan muchos mas.  Pero vale la pena conocer aquellos que son por decirlo de alguna manera «populares».


Puerto Descripción
1 TCP Port Service Multiplexer (TCPMUX)
5 Remote Job Entry (RJE)
7 ECHO
18 Message Send Protocol (MSP)
20 FTP — Data
21 FTP — Control
22 SSH Remote Login Protocol
23 Telnet
25 Simple Mail Transfer Protocol (SMTP)
29 MSG ICP
37 Time
42 Host Name Server (Nameserv)
43 WhoIs
49 Login Host Protocol (Login)
53 Domain Name System (DNS)
69 Trivial File Transfer Protocol (TFTP)
70 Gopher Services
79 Finger
80 HTTP
103 X.400 Standard
108 SNA Gateway Access Server
109 POP2
110 POP3
115 Simple File Transfer Protocol (SFTP)
118 SQL Services
119 Newsgroup (NNTP)
137 NetBIOS Name Service
139 NetBIOS Datagram Service
143 Interim Mail Access Protocol (IMAP)
150 NetBIOS Session Service
156 SQL Server
161 SNMP
179 Border Gateway Protocol (BGP)
190 Gateway Access Control Protocol (GACP)
194 Internet Relay Chat (IRC)
197 Directory Location Service (DLS)
389 Lightweight Directory Access Protocol (LDAP)
396 Novell Netware over IP
443 HTTPS
444 Simple Network Paging Protocol (SNPP)
445 Microsoft-DS
458 Apple QuickTime
546 DHCP Client
547 DHCP Server
563 SNEWS
569 MSN
1080 Socks

Desde luego algunos de estos puertos no se usan de forma obligatoria, los de http o https pueden cambiar, sin embargo los navegadores apuntan por default a estos puertos y si son cambiados se deben escribir explicitamente junto con la dirección IP del servicio al que se está accediendo.

Los gurús y el trabajo en equipo

Sin duda, siempre existen personas brillantes que se distinguen por su buen sentido común, curiosidad y capacidad para resolver problemas difíciles. Pero siempre he sospechado que la imagen del gurú está sobrevalorada.

Algunas malas experiencias me dicen que esto podría ser así.  En cierta ocasión, durante el desarrollo de un proyecto mas o menos grande y en una demostración de capacidades, el líder del equipo, que se sabía muy bueno en el desarrollo de software (el gurú), comenzó a utilizar una serie de tecnologías y frameworks de moda para impresionar al cliente y al administrador de proyecto.  Como resultado, los que tenían menos experiencia comenzaron a sufrir con la curva de aprendizaje y se enfocaron mas a conocer las nuevas tecnologías que al modelo de negocio. El desarrollo se terminó con una aplicación robusta tecnológicamente, pero poco amigable para el cliente y por supuesto en mas tiempo del que se esperaba. Un pequeño desastre.

En otras ocasiones, me he topado con el típico personaje que es capaz de resolver problemas difíciles, pero que cuando tienes que dar mantenimiento a su código o simplemente necesitas usarlo, este te parece tan desordenado que te dan ganas de hacerlo de nuevo.

Otro de los riesgos de tener a una persona que tiene todo el dominio sobre cierta tecnología, herramienta o el conocimiento mas crítico de un proyecto, es que puede simplemente irse, con el todo su conocimiento.

Me agradan mas los equipos de trabajo donde los problemas difíciles o algunas decisiones tecnológicas se resuelven entre varios.

Los gurús se equivocan como cualquier otro.

Además, cuando te autoproclamas gurú, puedes quedarte solo a la hora de resolver problemas difíciles.  Creo que no hay necesidad de que esto sea así, porque el criterio para resolver un problema crítico se reduce al de una sola persona y no creo que esto sea muy conveniente.

Cuando alguien te hace una pregunta complicada sobre algún problema o error, es probable que ella misma tenga mas capacidad para responderla, ya que conoce mejor el contexto del problema.  Por lo que mas que tratar de dar una solución es mejor dar un punto de vista o pistas sobre como resolver el problema.

El protagonismo es algo que nos puede seducir a todos, pero yo me lo pensaría mucho antes de adoptar una postura de este tipo. Sobre todo cuando de lo que se trata es hacer mas agradable y profesional tu trabajo.  Desde luego no estoy diciendo que todos los gurús son malos, de hecho también he conocido a algunos muy buenos. Pero son los menos.

Un hábito que recomiendo a todos es que cuando encuentras la solución a un problema difícil, la comentes a tus demás compañeros. Esto permite tener una base de conocimiento colectiva y evita tener que investigar demasiado sobre un problema que ya se ha sido resuelto con anterioridad.

Tómate con calma eso de ser gurú, puedes serlo sin hacer alarde.  🙂

Pregunta Java: wait() sin el monitor correcto

Piensa la respuesta antes de abrirla. Todas las opciones parecen razonables, y casi siempre hay un detalle que lo cambia todo.

Pregunta Java · Threads

¿Qué sucederá al tratar de compilar y ejecutar el siguiente código?

public class Test {

    public static void main(String[] args) {
        String mensaje = "Hola";
        synchronized (args) {
            try {
                mensaje.wait();
            } catch (InterruptedException e) {
            }
        }
        System.out.println(mensaje);
    }
}
  1. La compilación falla.
  2. Imprime "Hola".
  3. Una IllegalMonitorStateException es lanzada en tiempo de ejecución.
  4. Nada se imprime, el thread principal solo espera en la línea 7.
Ver la respuesta

Respuesta: 3.

java TestException in thread "main" java.lang.IllegalMonitorStateException: current thread is not owner
	at java.base/java.lang.Object.wait0(Native Method)
	at java.base/java.lang.Object.wait(Object.java:389)
	at java.base/java.lang.Object.wait(Object.java:351)
	at Test.main(Test.java:7)

Compila sin problemas: wait() es un método de Object y cualquier objeto lo tiene. El fallo llega al ejecutar. Para llamar a wait() sobre un objeto, el hilo tiene que tener el monitor de ese mismo objeto, y aquí tiene el de args, no el de mensaje. Estar dentro de un bloque synchronized no basta: tiene que ser synchronized (mensaje).

La trampa está en la opción 4: con el monitor correcto, el hilo sí se quedaría esperando para siempre en la línea 7, porque nadie llama a notify().

Pregunta publicada en 2013 y revisada en octubre de 2026. La respuesta se comprobó compilando y ejecutando el código con Java 25 LTS en un contenedor limpio; las salidas están copiadas de esa ejecución.

Suele pasar…

Texto sobre fondo gris azulado: «Suele pasar. Llevas horas buscando un error en tu código y cuando comienzas a explicarlo a alguien más para que te ayude… ¡lo encuentras! :)».

«Suele pasar»

Tiene nombre: depuración con patito de goma. Al explicar el código en voz alta, línea por línea, te obligas a revisar lo que das por supuesto, y ahí suele estar el error. Funciona incluso explicándoselo a un patito de goma.