RA4 de Programación de Servicios y Procesos · DAM

Contenido verificado asociado a este RA

Conceptos clave

Errores que conviene evitar

• {"error":"Bloquear el hilo principal (UI) con operaciones de red.","causa":"Las operaciones de red son lentas y bloqueantes. Ejecutarlas en el hilo de la interfaz de usuario (por ejemplo, en Android o una aplicación de escritorio) congela la aplicación hasta que se completa la respuesta, generando una mala experiencia de usuario y posibles errores de 'Aplicación no responde'.","correccion":"Realizar siempre las operaciones de red en un hilo de trabajo separado (background thread). Utilizar mecanismos como `AsyncTask` (en Android clásico), `Executors` o `CompletableFuture` en Java para gestionar la concurrencia y actualizar la UI de forma segura una vez obtenidos los resultados."}
• {"error":"No cerrar las conexiones o los streams.","causa":"Olvidar invocar `disconnect()` en la conexión o `close()` en los streams (`InputStream`, `OutputStream`, etc.). Esto provoca una fuga de recursos (resource leak), agotando los descriptores de fichero del sistema operativo y pudiendo impedir que la aplicación o el sistema abran nuevas conexiones.","correccion":"Utilizar siempre un bloque `finally` o, preferiblemente, la construcción `try-with-resources` de Java para garantizar que todos los recursos (conexiones, streams) se cierren automáticamente, incluso si se produce una excepción."}
• {"error":"Usar un puerto privilegiado (<1024) sin permisos de administrador.","causa":"Los sistemas operativos tipo Unix (Linux, macOS) reservan los puertos del 0 al 1023 para servicios del sistema. Intentar que un `ServerSocket` escuche en uno de estos puertos (ej. 80 para HTTP) desde una cuenta de usuario normal lanzará una `BindException` por permisos denegados.","correccion":"Para el desarrollo y pruebas, utilizar siempre puertos no privilegiados (superiores a 1023, típicamente >49151). En un entorno de producción, la aplicación se ejecutaría con los permisos necesarios o se configuraría un proxy inverso (como Nginx) que escuche en el puerto 80/443 y redirija el tráfico al puerto no privilegiado de la aplicación."}
• {"error":"No gestionar correctamente el fin de la comunicación por parte del cliente.","causa":"Si un cliente cierra la conexión abruptamente, el método `readLine()` en el servidor puede devolver `null`. Si el código no comprueba esta condición, intentará procesar un valor nulo, resultando en una `NullPointerException` que puede hacer caer el hilo que atiende a ese cliente o incluso el servidor si no está bien estructurado.","correccion":"El bucle de lectura del servidor debe comprobar explícitamente si la línea leída es `null` y, en ese caso, interpretar que el cliente ha cerrado la conexión, procediendo a cerrar los recursos de ese lado de forma ordenada."}
• {"error":"Modificar datos compartidos desde múltiples hilos sin sincronización.","causa":"Varios hilos `ClientHandler` intentan leer y escribir en una misma estructura de datos (ej. un `HashMap` que guarda el estado de los usuarios) sin ningún mecanismo de bloqueo. Esto lleva a condiciones de carrera, donde el resultado final depende del orden impredecible en que los hilos son ejecutados por el planificador del SO, causando datos corruptos, inconsistentes o excepciones como `ConcurrentModificationException`.","correccion":"Utilizar estructuras de datos seguras para la concurrencia (ej. `ConcurrentHashMap` en lugar de `HashMap`) o proteger el acceso a las secciones críticas del código (donde se modifican los datos compartidos) usando bloques `synchronized` o `ReentrantLock` para asegurar que solo un hilo puede modificar el recurso a la vez."}
• {"error":"Iniciar la lógica del cliente en el hilo principal llamando a `run()` en lugar de `start()`.","causa":"Un error conceptual común es llamar a `handler.run()` en lugar de `new Thread(handler).start()`. Invocar `run()` directamente no crea un nuevo hilo; simplemente ejecuta el método `run()` en el hilo actual (el hilo principal del servidor). Esto anula por completo el propósito de la concurrencia, y el servidor volverá a comportarse de forma secuencial y bloqueante.","correccion":"Recordar siempre que para iniciar un nuevo hilo de ejecución se debe instanciar un `Thread` y llamar a su método `start()`. El sistema operativo se encargará de crear el hilo y llamar a su método `run()` en el momento apropiado."}
• {"error":"Usar `System.out.println` para depurar un servicio en producción.","causa":"Los mensajes impresos en la consola estándar son efímeros, no tienen niveles de severidad, no se pueden filtrar fácilmente y se pierden si el servicio se ejecuta como un demonio o servicio de sistema. Es imposible analizar problemas pasados o correlacionar eventos de diferentes hilos.","correccion":"Integrar un framework de logging desde el inicio del proyecto. Configurar diferentes 'appenders' para que los logs se guarden en archivos rotatorios y, opcionalmente, se muestren en consola durante el desarrollo. Registrar información útil como timestamps, nivel, ID de hilo y mensajes descriptivos."}
• {"error":"Documentación que solo describe 'qué' hace el código, no 'por qué'.","causa":"Comentarios como `// incrementa i` son inútiles, ya que el código `i++;` es autoevidente. La documentación valiosa explica la intención, las decisiones de diseño o las precondiciones que no son obvias en el código.","correccion":"Enfocar la documentación en el 'porqué'. Por ejemplo: `// Usamos un ConcurrentHashMap para evitar condiciones de carrera al acceder al estado de los usuarios desde múltiples hilos ClientHandler.` Este tipo de comentario ayuda a futuros mantenedores a entender el diseño y a no introducir errores."}

Qué se evalúa en este RA