1. Definition of Artificial Intelligence

Artificial intelligence is a branch of computer science focused on building systems capable of performing tasks that are normally associated with human intelligence. These tasks may include recognizing patterns, classifying information, making decisions, solving problems, interpreting language, predicting behavior or generating new content.

This does not mean that a machine thinks, understands or has consciousness. An AI system can produce a useful response without truly understanding what it is doing. For this reason, it is important to distinguish between intelligent behavior and real understanding.

A machine may appear intelligent because it answers correctly, classifies data accurately or predicts outcomes with precision. However, internally, it operates through rules, data, statistical models or machine learning techniques.

In simple terms, an AI system receives an input, processes it through a model and produces an output. That output may be a prediction, a classification, a recommendation, a written response, an image, an alert or an action in a physical environment.

2. The Difficulty of Defining Intelligence

Before defining artificial intelligence, it is important to understand that human intelligence itself is difficult to define. One person may be highly skilled at mathematical reasoning but struggle with writing. Another may learn languages easily but have less ability in logical analysis. Others may excel in creativity, music, communication or spatial perception.

For this reason, artificial intelligence should not be understood as a direct copy of the human mind. In practice, current AI does not attempt to reproduce all forms of human intelligence. Instead, it focuses on building systems that can solve specific tasks efficiently.

AI is usually evaluated by its external results. If a system detects fraud, translates text, answers questions or recommends content effectively, we say that it performs an intelligent task. However, this does not prove that the system understands the meaning of what it is doing.

This distinction is fundamental: modern AI can simulate intelligent behavior, but it does not possess human understanding.

3. Symbolic AI and Rule-Based Systems

The first approaches to artificial intelligence tried to represent reasoning through symbols and rules. This approach is known as symbolic AI.

The basic idea was that a problem could be described through an initial state, a set of rules and a final goal. If the system applied the rules correctly, it could reach a solution. Within this approach, Allen Newell and Herbert Simon developed the General Problem Solver, an early attempt to create a machine capable of solving problems through formal reasoning.

Expert systems also emerged from this tradition. In these systems, the knowledge of human specialists was translated into explicit rules. For example, in a financial system, an expert could define rules to evaluate credit risk based on income, debt, payment history and other variables. The system might appear to reason, but in reality, it was only executing instructions written in advance.

This approach was important because it showed that machines could solve useful tasks through rules. However, it also had a clear limitation: it depended on humans anticipating and programming possible situations beforehand.

4. The Limits of Symbolic AI

Symbolic AI works well when the environment is simple, stable and controlled. The problem appears when the real world introduces exceptions, ambiguity, incomplete data and too many possible combinations.

A rule-based system requires someone to write in advance what the system should do in each situation. This may work for small problems, but it becomes unmanageable when there are thousands or millions of possible scenarios. This problem is known as combinatorial explosion.

The conclusion was important: it was not practical to manually program all intelligence into a system. Instead of writing every possible rule, researchers needed systems capable of learning patterns from examples.

This shift led to the rise of machine learning.

5. Machine Learning: Learning from Data

Machine learning is an approach within artificial intelligence in which a system learns patterns from data instead of depending only on rules written by humans.

In a symbolic system, knowledge is programmed directly. In machine learning, knowledge is acquired through training. The system receives examples, identifies regularities and adjusts its behavior to improve its results.

An important historical example is Arthur Samuel’s checkers program from 1959. The system played games, observed which moves produced better outcomes and adjusted its strategy over time. It was not programmed with every possible move. Instead, it improved through experience.

The core idea is simple: if a system receives enough examples, it can identify patterns that allow it to make better decisions in new situations.

This does not mean that the machine understands what it is doing. It means that it can detect useful statistical relationships within the data.

6. Massive Data and the Growth of Machine Learning

For decades, machine learning was limited by the lack of digital data. The idea existed, but systems did not have enough information to learn complex patterns effectively.

This changed with the rise of the internet and large-scale digitalization. People and organizations began generating enormous amounts of data: documents, images, audio, video, purchases, searches, user interactions, forms, financial records, application activity and platform behavior.

This transformed machine learning into one of the dominant approaches in modern AI. A system can analyze volumes of information that would be impossible for humans to review manually and identify useful patterns for organizations.

A more technical example would be an online education platform. Each user interaction can generate data: how long a student watches a lesson, where they pause, where they stop watching, which module they repeat, which course they complete and where they lose interest. Manually analyzing millions of records would be impossible. A machine learning model can detect dropout patterns, identify difficult content, recommend modules or improve the course structure.

The value is not simply in storing data. The real value appears when data helps improve decisions, automate processes or anticipate behavior.

7. Artificial Neural Networks

One of the most important approaches within machine learning is the artificial neural network. These are computational models loosely inspired by the structure of the brain, although they are not real copies of the human brain.

A neural network receives input data, processes it through internal layers, and produces an output. The first layer is called the input layer. The last layer is the output layer. Between them are hidden layers, which progressively transform the information.

Learning occurs by adjusting internal values called weights. At the beginning, these weights do not represent useful knowledge. During training, the network processes examples, compares its output with the expected answer and modifies its weights to reduce error. This process is repeated many times until the model improves.

A technical example is financial fraud detection. The model’s input may include the transaction amount, time of day, type of business, approximate location, device used, customer history and transaction frequency. The output may be a risk probability. The network does not “understand” fraud as a human analyst would. Instead, it learns statistical combinations that commonly appear in normal or suspicious transactions.

Neural networks are useful because they can detect complex patterns in large amounts of data. However, they also introduce a challenge: the more complex the network becomes, the harder it may be to explain exactly how it reached a conclusion.

8. The Black Box Problem

Many advanced models work like a black box. They receive data, perform internal transformations and produce an output, but the intermediate process may be difficult for a person to interpret.

This is not always a serious problem. If a system recommends the wrong movie, the impact is low. But in areas such as healthcare, credit, insurance, security, or autonomous driving, accuracy is not enough. It also matters why the system made a decision.

For this reason, the use of AI in sensitive contexts requires human oversight, error evaluation, responsibility criteria, and explanation mechanisms. A model may find patterns that humans cannot easily perceive, but that does not mean all of its conclusions should be accepted automatically.

9. Natural Language Processing

Natural language processing, or NLP, is the area of artificial intelligence that allows machines to work with human language. Its goal is to enable a system to receive text or speech, interpret the user’s intention, and produce a useful output.

Human language is difficult for machines because it does not work like an exact command. People use incomplete sentences, ambiguity, context, mistakes, indirect expressions, and meanings that depend on the situation.

Older search systems depended heavily on keywords. If a user typed certain terms, the system looked for matches. Modern NLP systems try to go further: they analyze relationships between words, context, intention, and probable meaning.

NLP is used in automatic translation, virtual assistants, chatbots, message classification, document summarization, sentiment analysis, speech transcription, and response generation.

Even so, the technical point remains the same: the system does not understand language as a human being does. It learns statistical patterns from language use and applies those patterns to produce useful responses.

10. Robotics and AI in the Physical World

Robotics allows machines to perform physical tasks. Not all robotics uses advanced AI. Many industrial robots operate through traditional programming: they repeat precise movements, assemble parts, transport objects, or execute tasks in controlled environments.

The difference appears when the robot must act in a changing environment. In that case, it may need sensors, cameras, machine learning models, and decision-making capabilities.

An autonomous vehicle illustrates this difference well. Turning the wheel or applying the brakes is not the central problem. The difficult part is deciding when to do it. The system must process signals from the environment, identify obstacles, pedestrians, vehicles, lanes, traffic lights, and unexpected situations. At that point, robotics is no longer only a mechanical problem; it also becomes a data problem.

However, in the physical world, errors have a higher cost. A bad digital recommendation may be annoying. A bad robotic decision can cause real damage. For this reason, many robotic systems still use simple rules when the environment is controlled and safety is a priority.

11. The Internet of Things and AI

The Internet of Things, or IoT, refers to physical objects connected to the internet that include sensors and can send data. These may include smart watches, industrial sensors, cameras, appliances, vehicles, medical devices, or security systems.

The importance of IoT for AI is that it turns the physical world into a constant source of data. In the past, many systems mainly analyzed digital data: searches, clicks, online purchases, or documents. With IoT, systems can also collect information about location, movement, temperature, physical activity, heart rate, human presence, machine usage, or environmental conditions.

The relationship is direct: the device captures data, the system processes it, and AI detects patterns. Based on those patterns, it can anticipate failures, detect anomalies, adjust behavior, or activate automatic responses.

The benefit is clear: more data from the physical world can lead to better predictions and automation. However, there is also an important risk: privacy. Connected devices may collect sensitive information about habits, health, location, and behavior. For this reason, combining IoT with AI requires special care regarding what data is collected, who uses it, and for what purpose.

12. Weak AI and Strong AI

Weak AI is artificial intelligence designed to perform specific tasks. This is the type of AI that exists today. It can be highly effective in a particular domain, but it does not possess general understanding or consciousness.

A recommendation system, a fraud detector, an automatic translator, a chatbot, or an image generator are examples of weak AI. They can produce useful results, but they do not understand the world as a human does.

Strong AI would be an artificial intelligence with real understanding, general reasoning, conceptual autonomy, and possibly consciousness. It would not merely simulate intelligence; it would possess genuine intelligence.

Strong AI does not currently exist. Even the most advanced modern models are still weak AI because they operate through data, patterns, and statistical models.

13. Predictive AI

Predictive AI uses historical data to estimate future outcomes. It does not truly predict the future. It calculates probabilities based on patterns found in past data.

This approach is used to recommend products, detect fraud, estimate credit risk, anticipate customer churn, personalize content, forecast demand, or classify behavior.

The logic is usually similar: the system observes previous data, identifies repeated patterns, and estimates which result is most likely.

Its strength is that it works very well for clearly defined problems. Its limitation is that each model is usually optimized for a specific task. A system trained to detect fraud is not necessarily useful for answering general questions or generating content.

14. Generative AI

Generative AI is a type of artificial intelligence capable of producing new content from patterns learned in large amounts of data.

It can generate text, images, code, audio, video, summaries, answers, or simulations. It does not create from nothing. It generates content by combining patterns learned during training.

In language models, the system learns relationships between words, phrases, topics, and contexts. When it responds, it generates text step by step, estimating which fragment is most likely according to the user’s input and the patterns it has learned.

In generative image models, the system learns visual relationships between objects, shapes, styles, lighting, and composition. It can then produce a new image based on those relationships.

Generative AI became possible through the combination of three factors: large amounts of digital data, deep learning models, and greater computing power.

The main difference between predictive AI and generative AI is the type of output. Predictive AI estimates probabilities about an outcome. Generative AI produces new content.

15. The Relationship Between Data, Patterns, and Value

Modern AI is built around one central idea: transforming data into useful outputs.

Symbolic AI used explicit rules. Machine learning learns patterns from data. Neural networks detect more complex relationships. Predictive AI uses those patterns to estimate future outcomes. Generative AI uses them to produce new content. NLP applies these methods to human language. Robotics and IoT bring AI into the physical world.

The value of AI is not that the machine “thinks.” Its value is that it can process information at a scale impossible for humans and identify useful patterns for decision-making, automation, or content generation.

Final Summary

Artificial intelligence is a branch of computer science that builds systems capable of performing tasks associated with human intelligence. However, this does not mean that these systems truly understand what they are doing.

Symbolic AI was one of the first approaches. It used symbols and explicit rules. It worked well for simple problems but struggled when too many possible combinations appeared.

Machine learning emerged as an alternative. Instead of programming every rule manually, the system learns patterns from data.

Artificial neural networks are machine learning models that process data through layers and adjust internal weights during training. They are useful for complex patterns, but they can be difficult to interpret.

The black box problem appears when a model produces a useful output, but it is not easy to explain how it reached that conclusion.

Natural language processing allows machines to work with human text or speech. It does not understand language like a person, but it identifies patterns in language and intention.

Robotics shows how AI can act in the physical world. In this context, errors are more serious, and safety becomes essential.

IoT turns physical objects into sources of data. Sensors and connected devices allow AI to analyze real-world patterns.

Weak AI is the AI that exists today: systems useful for specific tasks, without consciousness or real understanding. Strong AI would be an artificial intelligence with genuine understanding, but it does not exist yet.

Predictive AI uses historical data to estimate future probabilities. Generative AI uses learned patterns to produce new content.

The main idea is this: modern AI does not think like a human being. It processes data, detects patterns, and produces useful outputs through statistical models.

1. Definición de inteligencia artificial

La inteligencia artificial es una rama de la informática que estudia cómo construir sistemas capaces de realizar tareas que normalmente asociamos con inteligencia humana. Esto incluye reconocer patrones, clasificar información, tomar decisiones, resolver problemas, interpretar lenguaje, predecir comportamientos o generar contenido.

Esta definición no significa que una máquina piense, entienda o tenga conciencia. Un sistema de IA puede producir una respuesta útil sin comprender realmente lo que está haciendo. Lo importante es distinguir entre comportamiento inteligente y comprensión real. Una máquina puede parecer inteligente porque responde bien, clasifica correctamente o predice con precisión, pero internamente opera mediante reglas, datos, modelos estadísticos o aprendizaje automático.

En términos simples, un sistema de IA recibe una entrada, la procesa mediante algún modelo y produce una salida. Esa salida puede ser una predicción, una clasificación, una recomendación, una respuesta escrita, una imagen, una alerta o una acción dentro de un entorno físico.

2. El problema de definir inteligencia

Antes de hablar de inteligencia artificial, hay que entender que la inteligencia humana tampoco es fácil de definir. Una persona puede ser muy buena resolviendo problemas matemáticos y mala escribiendo. Otra puede tener facilidad para aprender idiomas, pero poca habilidad para el razonamiento lógico. Otra puede destacar en creatividad, música, comunicación o percepción espacial.

Por eso, cuando se habla de inteligencia artificial, no conviene imaginar una copia de la mente humana. En la práctica, la IA actual no busca reproducir toda la inteligencia humana, sino construir sistemas capaces de resolver tareas concretas de manera eficiente.

La IA se evalúa principalmente por sus resultados externos. Si un sistema detecta fraude, traduce texto, responde preguntas o recomienda contenido con buenos resultados, se dice que realiza una tarea inteligente. Pero eso no demuestra que el sistema comprenda el significado de lo que hace.

Esta diferencia es fundamental para todo el documento: la IA actual puede simular capacidades inteligentes, pero no posee comprensión humana.

3. IA simbólica y sistemas basados en reglas

Los primeros enfoques de inteligencia artificial intentaron representar el razonamiento mediante símbolos y reglas. Esta corriente se conoce como IA simbólica.

La idea era que un problema podía describirse mediante un estado inicial, un conjunto de reglas y un objetivo. Si el sistema aplicaba correctamente esas reglas, podía llegar a una solución. Dentro de este enfoque apareció el General Problem Solver, desarrollado por Allen Newell y Herbert Simon, que intentaba construir una máquina capaz de resolver problemas mediante razonamiento formal.

También surgieron los sistemas expertos. En ellos, el conocimiento de especialistas humanos se transformaba en reglas explícitas. Por ejemplo, en un sistema financiero, un experto podía definir reglas para evaluar riesgo crediticio según ingresos, deuda, historial de pagos y otros factores. El sistema parecía tomar decisiones razonadas, pero en realidad solo ejecutaba instrucciones previamente escritas.

Este enfoque fue importante porque mostró que una máquina podía resolver tareas útiles mediante reglas. Sin embargo, tenía un límite claro: dependía de que los humanos anticiparan y programaran las situaciones posibles.

4. Límite de la IA simbólica

La IA simbólica funciona bien cuando el entorno es simple, estable y controlado. El problema aparece cuando el mundo real introduce excepciones, ambigüedades, datos incompletos y demasiadas combinaciones posibles.

Un sistema basado en reglas necesita que alguien escriba de antemano qué debe hacer en cada situación. Eso puede funcionar en problemas pequeños, pero se vuelve inmanejable cuando existen miles o millones de escenarios posibles. A este problema se lo conoce como explosión combinatoria.

La conclusión fue importante: no era práctico programar manualmente toda la inteligencia dentro del sistema. En lugar de escribir todas las reglas, hacía falta crear sistemas capaces de aprender patrones a partir de ejemplos.

Ahí aparece el cambio central hacia el machine learning.

5. Machine learning: aprender desde datos

El machine learning, o aprendizaje automático, es un enfoque de IA donde el sistema aprende patrones a partir de datos en lugar de depender únicamente de reglas escritas por humanos.

En un sistema simbólico, el conocimiento se programa directamente. En machine learning, el conocimiento se obtiene mediante entrenamiento. El sistema recibe ejemplos, identifica regularidades y ajusta su comportamiento para mejorar sus resultados.

Un caso histórico importante fue el programa de damas de Arthur Samuel en 1959. El sistema jugaba contra sí mismo, observaba qué movimientos producían mejores resultados y ajustaba su estrategia. No se le programaron todas las jugadas posibles. Aprendía a mejorar mediante experiencia.

La idea de fondo es simple: si un sistema recibe suficientes ejemplos, puede encontrar patrones que le permitan tomar mejores decisiones en casos nuevos.

Esto no significa que la máquina entienda lo que hace. Significa que puede detectar relaciones estadísticas útiles dentro de los datos.

6. Datos masivos y crecimiento del machine learning

Durante décadas, el machine learning estuvo limitado por la falta de datos digitales. La idea existía, pero los sistemas no tenían suficiente información para aprender patrones complejos.

Esa situación cambió con internet y la digitalización masiva. Las personas y organizaciones empezaron a generar enormes cantidades de datos: documentos, imágenes, audios, videos, compras, búsquedas, interacciones, formularios, registros financieros, actividad en aplicaciones y comportamiento dentro de plataformas.

Esto convirtió al machine learning en un enfoque dominante dentro de la IA moderna. Un sistema puede analizar volúmenes de información imposibles de revisar manualmente y encontrar patrones útiles para una organización.

Un ejemplo más técnico es una plataforma de educación online. Cada interacción del usuario puede generar datos: cuánto tiempo mira una clase, dónde pausa, dónde abandona, qué módulo repite, qué curso termina y en qué punto pierde interés. Analizar manualmente millones de registros sería inviable. Un modelo de machine learning puede detectar patrones de abandono, identificar contenidos difíciles, recomendar módulos o mejorar la estructura del curso.

El valor no está solamente en almacenar datos. El valor aparece cuando esos datos permiten mejorar decisiones, automatizar procesos o anticipar comportamientos.

7. Redes neuronales artificiales

Dentro del machine learning, uno de los enfoques más importantes son las redes neuronales artificiales. Son modelos computacionales inspirados de manera general en la estructura del cerebro, aunque no son una copia real del cerebro humano.

Una red neuronal recibe datos de entrada, los procesa a través de capas internas y produce una salida. La primera capa se llama capa de entrada. La última se llama capa de salida. Entre ambas se encuentran las capas ocultas, que transforman progresivamente la información.

El aprendizaje ocurre ajustando valores internos llamados pesos. Al comienzo, esos pesos no representan conocimiento útil. Durante el entrenamiento, la red procesa ejemplos, compara su salida con la respuesta esperada y modifica sus pesos para reducir el error. Ese proceso se repite muchas veces hasta que el modelo mejora.

Un ejemplo técnico puede ser la detección de fraude financiero. La entrada del modelo puede incluir monto de la operación, horario, tipo de comercio, ubicación aproximada, dispositivo utilizado, historial del cliente y frecuencia de transacciones. La salida puede ser una probabilidad de riesgo. La red no “entiende” el fraude como lo haría un analista humano; aprende combinaciones estadísticas que suelen aparecer en operaciones normales o sospechosas.

Las redes neuronales son útiles porque pueden detectar patrones complejos en grandes volúmenes de datos. Pero también introducen un problema: cuanto más compleja es la red, más difícil puede ser explicar exactamente cómo llegó a una conclusión.

8. El problema de la caja negra

Muchos modelos avanzados funcionan como una caja negra. Reciben datos, realizan transformaciones internas y producen una salida, pero el proceso intermedio puede ser difícil de interpretar para una persona.

Esto no siempre es grave. Si un sistema recomienda una película incorrecta, el daño es bajo. Pero en áreas como salud, crédito, seguros, seguridad o conducción autónoma, no alcanza con que el sistema acierte muchas veces. También importa entender por qué tomó una decisión.

Por eso, el uso de IA en contextos sensibles requiere control humano, evaluación de errores, criterios de responsabilidad y mecanismos de explicación. Un modelo puede encontrar patrones que los humanos no perciben, pero eso no significa que todas sus conclusiones deban aceptarse automáticamente.

9. Procesamiento del lenguaje natural

El procesamiento del lenguaje natural, o NLP, es el área de la IA que permite a las máquinas trabajar con lenguaje humano. Su objetivo es que un sistema pueda recibir texto o voz, interpretar la intención del usuario y producir una salida útil.

El lenguaje humano es difícil para una máquina porque no funciona como un comando exacto. Las personas usan frases incompletas, ambigüedades, contexto, errores, expresiones indirectas y significados que dependen de la situación.

Los sistemas antiguos de búsqueda dependían mucho de palabras clave. Si el usuario escribía ciertos términos, el sistema buscaba coincidencias. Los sistemas modernos de NLP intentan ir más allá: analizan relaciones entre palabras, contexto, intención y significado probable.

El NLP se usa en traducción automática, asistentes virtuales, chatbots, clasificación de mensajes, resumen de documentos, análisis de sentimiento, transcripción de voz y generación de respuestas.

Aun así, el punto técnico sigue siendo el mismo: el sistema no comprende el lenguaje como una persona. Aprende patrones estadísticos del uso del lenguaje y los utiliza para producir respuestas útiles.

10. Robótica e IA en el mundo físico

La robótica permite que una máquina realice tareas físicas. No toda robótica usa IA avanzada. Muchos robots industriales funcionan mediante programación tradicional: repiten movimientos precisos, ensamblan piezas, transportan objetos o ejecutan tareas en entornos controlados.

La diferencia aparece cuando el robot debe actuar en un entorno cambiante. En ese caso, puede necesitar sensores, cámaras, modelos de machine learning y capacidad de decisión.

Un vehículo autónomo muestra bien esta diferencia. Mover el volante o frenar no es el problema central. Lo difícil es interpretar cuándo hacerlo. El sistema debe procesar señales del entorno, distinguir obstáculos, peatones, vehículos, carriles, semáforos y situaciones imprevistas. Ahí la robótica deja de ser solo un problema mecánico y se convierte también en un problema de datos.

Sin embargo, en el mundo físico los errores tienen mayor costo. Una mala recomendación digital puede ser molesta; una mala decisión de un robot puede causar daño real. Por eso, muchos sistemas robóticos siguen usando reglas simples cuando el entorno es controlado y la seguridad es prioritaria.

11. Internet de las Cosas e IA

El Internet de las Cosas, o IoT, se refiere a objetos físicos conectados a internet que incorporan sensores y pueden enviar datos. Pueden ser relojes inteligentes, sensores industriales, cámaras, electrodomésticos, vehículos, dispositivos médicos o sistemas de seguridad.

La importancia del IoT para la IA está en que convierte el mundo físico en una fuente constante de datos. Antes, muchos sistemas analizaban principalmente datos digitales: búsquedas, clics, compras online o documentos. Con IoT, también se pueden registrar ubicación, movimiento, temperatura, actividad física, ritmo cardíaco, presencia de personas, uso de máquinas o condiciones ambientales.

La relación es directa: el dispositivo captura datos, el sistema los procesa y la IA detecta patrones. Con esos patrones puede anticipar fallas, detectar anomalías, ajustar comportamientos o activar respuestas automáticas.

El beneficio es claro: más datos del mundo físico permiten mejores predicciones y automatizaciones. Pero también aparece un riesgo importante: privacidad. Los dispositivos conectados pueden registrar información muy sensible sobre hábitos, salud, ubicación y comportamiento. Por eso, IoT combinado con IA requiere especial cuidado sobre qué datos se recolectan, quién los usa y con qué finalidad.

12. IA débil e IA fuerte

La IA débil es la inteligencia artificial diseñada para realizar tareas específicas. Es la IA que existe actualmente. Puede ser muy eficiente en un dominio concreto, pero no posee comprensión general ni conciencia.

Un sistema de recomendación, un detector de fraude, un traductor automático, un chatbot o un modelo generador de imágenes son ejemplos de IA débil. Pueden producir resultados útiles, pero no entienden el mundo como una persona.

La IA fuerte sería una inteligencia artificial con comprensión real, razonamiento general, autonomía conceptual y posiblemente conciencia. No simularía inteligencia: tendría inteligencia genuina.

Actualmente no existe IA fuerte. Incluso los modelos modernos más avanzados siguen siendo IA débil, porque operan mediante datos, patrones y modelos estadísticos.

13. IA predictiva

La IA predictiva utiliza datos históricos para estimar resultados futuros. No adivina el futuro. Calcula probabilidades basadas en patrones del pasado.

Este enfoque se usa para recomendar productos, detectar fraude, estimar riesgo crediticio, anticipar abandono de clientes, personalizar contenido, prever demanda o clasificar comportamientos.

La lógica es siempre parecida: el sistema observa datos anteriores, identifica patrones repetidos y estima qué resultado es más probable.

Su fortaleza es que funciona muy bien en problemas definidos. Su límite es que normalmente cada modelo está optimizado para una tarea concreta. Un sistema entrenado para detectar fraude no necesariamente sirve para responder preguntas generales o generar contenido.

14. IA generativa

La IA generativa es un tipo de inteligencia artificial capaz de producir contenido nuevo a partir de patrones aprendidos en grandes volúmenes de datos.

Puede generar texto, imágenes, código, audio, video, resúmenes, respuestas o simulaciones. No crea desde la nada. Genera contenido combinando patrones aprendidos durante el entrenamiento.

En los modelos de lenguaje, el sistema aprende relaciones entre palabras, frases, temas y contextos. Cuando responde, genera texto paso a paso, estimando qué fragmento es más probable según la entrada del usuario y los patrones aprendidos.

En los modelos generativos de imágenes, el sistema aprende relaciones visuales entre objetos, formas, estilos, iluminación y composición. Luego puede producir una imagen nueva a partir de esas relaciones.

La IA generativa se volvió posible por la combinación de tres factores: grandes cantidades de datos digitales, modelos de aprendizaje profundo y mayor capacidad de cómputo.

Su diferencia con la IA predictiva está en el tipo de salida. La IA predictiva estima probabilidades sobre un resultado. La IA generativa produce contenido nuevo.

15. Relación entre datos, patrones y valor

Toda la IA moderna gira alrededor de una idea central: convertir datos en salidas útiles.

La IA simbólica usaba reglas explícitas. El machine learning aprende patrones desde datos. Las redes neuronales permiten detectar relaciones más complejas. La IA predictiva usa esos patrones para estimar resultados futuros. La IA generativa los usa para producir contenido nuevo. NLP aplica estos métodos al lenguaje humano. Robótica e IoT llevan la IA al mundo físico.

El valor de la IA no está en que la máquina “piense”, sino en que puede procesar información a una escala imposible para una persona y encontrar patrones útiles para tomar decisiones, automatizar tareas o generar contenido.

Resumen final

La inteligencia artificial es una rama de la informática que construye sistemas capaces de realizar tareas asociadas con inteligencia humana, pero eso no significa que esos sistemas comprendan lo que hacen.

La IA simbólica fue uno de los primeros enfoques. Usaba símbolos y reglas explícitas. Funcionaba en problemas simples, pero fallaba cuando aparecían demasiadas combinaciones posibles.

El machine learning surgió como alternativa: en lugar de programar todas las reglas, el sistema aprende patrones a partir de datos.

Las redes neuronales artificiales son modelos de machine learning que procesan datos en capas y ajustan pesos internos durante el entrenamiento. Son útiles para patrones complejos, pero pueden ser difíciles de interpretar.

El problema de la caja negra aparece cuando un modelo produce una salida útil, pero no es fácil explicar cómo llegó a esa conclusión.

El procesamiento del lenguaje natural permite que las máquinas trabajen con texto o voz humana. No entiende como una persona, pero identifica patrones de lenguaje e intención.

La robótica muestra cómo la IA puede actuar en el mundo físico. En ese contexto, el error es más costoso y la seguridad se vuelve central.

IoT convierte objetos físicos en fuentes de datos. Sensores y dispositivos conectados permiten que la IA analice patrones del mundo real.

La IA débil es la IA actual: sistemas útiles para tareas específicas, sin conciencia ni comprensión real. La IA fuerte sería una inteligencia artificial con comprensión genuina, pero todavía no existe.

La IA predictiva usa datos históricos para estimar probabilidades futuras. La IA generativa usa patrones aprendidos para producir contenido nuevo.

La idea principal de todo el tema es esta: la IA moderna no piensa como un ser humano; procesa datos, detecta patrones y produce salidas útiles mediante modelos estadísticos.

Document Structure Overview

This document progresses from conceptual foundations to runtime execution. Each section builds on the previous one, moving from principles (IoC) to implementation (Container, DI), behavioral extension (AOP), infrastructure concerns (Transactions, Persistence) and finally to the complete runtime execution model.

1. Inversion of Control (IoC)

1.1 Definition of IoC
1.2 Limitations of Traditional Architecture
1.3 Control Inversion Model
1.4 Core Principles of IoC
1.4.1 Separation of Responsibilities
1.4.2 Dependency Externalization
1.4.3 Dependency Inversion
1.4.4 Centralized Composition
1.4.5 Controlled Lifecycle Management
1.4.6 Managed Object Scope

2. IoC Container

2.1 Definition of the IoC Container
2.2 Responsibilities of the Container
2.3 Container Configuration
2.3.1 Annotation-Based Configuration
2.3.2 Java-Based Configuration
2.3.3 External Configuration
2.4 Bootstrapping Process

3. Object Management

3.1 Definition of Object Management
3.2 Bean Lifecycle
3.2.1 Instantiation
3.2.2 Dependency Injection Phase
3.2.3 Initialization Phase
3.2.4 Ready State
3.2.5 Destruction Phase
3.3 Bean Scope
3.3.1 Singleton Scope
3.3.2 Prototype Scope
3.3.3 Contextual Scopes (Request, Session)

4. Dependency Injection

(Operational realization of IoC, its concrete implementation)

4.1 DI as Implementation of IoC
4.2 Core Idea of Dependency Injection
4.3 Forms of Dependency Injection
4.3.1 Constructor Injection
4.3.2 Setter Injection
4.3.3 Field Injection
4.4 Dependency Resolution Process
4.5 Relationship with IoC Container

5. Aspect-Oriented Programming (AOP)

5.1 Definition of AOP
5.2 Separation of Cross-Cutting Concerns
5.3 Interception Mechanism
5.4 Proxy-Based Execution Model
5.5 Aspects
5.5.1 Pointcut
5.5.2 Advice
5.5.3 Weaving
5.6 Execution Flow with AOP
5.7 Relationship with IoC Container

6. Transaction Management

6.1 Definition of Transaction Management
6.2 Transactions as Aspects (AOP-Based Model)
6.3 Transaction Interception Flow
6.4 Transaction Lifecycle
6.4.1 Transaction Start
6.4.2 Execution Phase
6.4.3 Commit Phase
6.4.4 Rollback Phase
6.5 Declarative Transaction Model
6.6 Relationship with IoC and Dependency Injection

7. Persistence Integration

7.1 Definition of Persistence Integration
7.2 Persistence Components
7.2.1 Data Source
7.2.2 Entity Manager / Session
7.2.3 Repositories / Data Access Layer
7.3 Persistence Context
7.4 Integration with Container-Managed Transactions
7.5 Execution Flow with Persistence
7.6 Abstraction of Data Access

8. Runtime Execution Model

(Integration of all previous layers into a unified execution pipeline)

8.1 Definition of Runtime Execution Model
8.2 Structural Phase vs Runtime Phase
8.3 End-to-End Execution Flow
8.4 Unified Execution Pipeline
8.4.1 IoC Container
8.4.2 Dependency Injection
8.4.3 AOP
8.4.4 Transaction Management
8.4.5 Persistence Integration
8.5 Transparency of Execution
8.6 Determinism and Consistency

1. Inversion of Control (IoC)

1.1 Definition of IoC

Inversion of Control (IoC) is a software design principle in which the responsibility for object creation, dependency resolution, configuration, and lifecycle management is delegated from application code to an external system, typically referred to as a container or framework.

In a conventional design model, application components are responsible for constructing their own dependencies and controlling how objects are created and connected. This results in a system where object relationships and infrastructure concerns are embedded directly within business logic.

IoC reverses this control model. Application components no longer manage their own construction or dependency wiring. Instead, they declare their required dependencies and an external container is responsible for managing the complete object graph at runtime.

As a result, application code is decoupled from infrastructure concerns and can focus on domain-specific behavior, while the container assumes responsibility for system-level concerns.

1.2 Limitations of Traditional Architecture

In traditional architectures, object creation and dependency management are handled explicitly within application code.

First, tight coupling emerges between components. When a class directly instantiates its dependencies, it becomes bound to specific implementations, making substitution or extension difficult without modifying the original code.

Second, infrastructure concerns such as configuration, lifecycle handling and dependency wiring become intertwined with business logic. This mixing of responsibilities reduces clarity and makes the system harder to maintain and evolve.

Third, the absence of centralized control over object composition leads to fragmentation. Object relationships are defined across multiple classes, preventing a unified view of the system structure.

Finally, testability is significantly reduced. Since dependencies are created internally, replacing them with mock or alternative implementations requires invasive changes or complex workarounds.

These limitations highlight the need for a model in which object management is externalized and controlled in a consistent and centralized manner.

1.3 Control Inversion Model

The core idea of IoC lies in the inversion of control over object creation and composition.

In a traditional execution model, control flows from the application code outward:

• Classes instantiate their dependencies
• Objects define how they are connected
• Execution is driven directly by application logic

Under IoC, this flow is reversed:

• The container constructs objects
• Dependencies are resolved externally
• The application operates within a container-managed environment

This inversion transforms the role of application code. Instead of being responsible for system assembly, it becomes declarative in nature: components specify what they require, not how those requirements are fulfilled.

The container, in turn, acts as the central execution environment. It builds the object graph, enforces configuration rules, ensures that all components are correctly initialized and connected before use.

This model introduces a clear separation between:

• Structure → defined and managed by the container
• Behavior → implemented by application components

By shifting control outward, IoC establishes the foundation for all higher-level mechanisms, including dependency injection, lifecycle management and runtime behavior interception.

1.4 Core Principles of IoC

IoC is not a single mechanism but a set of architectural principles that define how responsibilities are distributed within a system.

1.4.1 Separation of Responsibilities

IoC enforces a strict separation between business logic and infrastructure concerns.

Application components are responsible only for implementing domain behavior. All concerns related to object creation, dependency wiring, configuration and lifecycle management are delegated to the container.

This separation ensures that business logic remains isolated, improving clarity, maintainability and architectural consistency.

1.4.2 Dependency Externalization

Under IoC, objects do not construct their own dependencies.

Instead, dependencies are provided externally by the container. This shifts the responsibility for object composition out of application code and into a centralized system.

As a result, classes no longer control their internal structure, which reduces coupling and ensures consistent dependency management across the application.

1.4.3 Dependency Inversion

IoC enforces dependency inversion at the architectural level.

High-level components depend on abstractions rather than concrete implementations. This decouples business logic from specific technologies or implementations, allowing components to be replaced or extended without modifying core logic.

This principle also enhances testability, as dependencies can be substituted with alternative implementations in isolation.

1.4.4 Centralized Composition

The structure of the application is defined in a centralized and declarative manner.

Instead of distributing object creation logic across multiple classes, the container maintains a unified definition of the object graph through configuration metadata.

This provides a single source of truth for component relationships, making the system easier to understand, modify and evolve.

1.4.5 Controlled Lifecycle Management

The lifecycle of application objects is fully managed by the container.

This includes instantiation, dependency injection, initialization and destruction. Application code does not explicitly control these phases.

By centralizing lifecycle management, the system ensures consistent behavior and removes repetitive infrastructure logic from business components.

1.4.6 Managed Object Scope

IoC introduces the concept of scope to control how objects are created and reused.

The container determines whether objects are shared across the application, created per request or instantiated on demand. This behavior is defined declaratively and enforced at runtime.

Inversion of Control is the foundational principle that redefines how applications are structured.

It removes responsibility for object creation from application code and delegates it to an external container. This shift establishes a clear separation between structure and behavior, enabling a modular, maintainable and extensible architecture.

All subsequent mechanisms, Dependency Injection, Object Management, AOP, Transaction Management and Persistence Integration are built upon this foundational model.

2. IoC Container

2.1 Definition of the IoC Container

The IoC Container is the runtime component responsible for realizing the Inversion of Control principle. It acts as the central execution system that constructs, configures and manages the complete set of application objects during runtime.

Instead of allowing application components to instantiate and wire their own dependencies, the container assumes full responsibility for assembling the object graph based on configuration metadata. This includes creating objects, resolving their dependencies and ensuring that all components are properly initialized before they are used.

The container defines the execution environment in which the application operates. Application components do not exist independently; they are created, connected and managed within the context of the container. As a result, structural concerns such as object relationships, lifecycle transitions and configuration are externalized and handled in a controlled and consistent manner.

2.2 Responsibilities of the Container

The IoC Container is responsible exclusively for infrastructure-level concerns related to system construction.

At its core, the container manages object instantiation. It creates application components based on configuration metadata, determining when and how each object should be constructed.

Once objects are instantiated, the container performs dependency resolution. It identifies required dependencies for each component and injects the appropriate instances, ensuring that all objects are correctly connected.

The container also controls the lifecycle of managed objects. It governs initialization and destruction.

Another key responsibility is maintaining the consistency of the object graph. The container ensures that dependencies are resolved deterministically, preventing duplication, misconfiguration or inconsistent state across the system.

In addition, the container may enhance objects at runtime through mechanisms such as proxy creation. This enables interception of method calls and supports higher-level features like aspect-oriented behavior and transaction management.

2.3 Container Configuration

Container Configuration defines how the IoC Container is instructed to construct and manage the application. Since the container has no inherent knowledge of which objects exist or how they are related, it relies on configuration metadata that describes the system structure.

This configuration acts as a blueprint of the application’s object graph. It specifies which components must be managed, how they are instantiated and how dependencies between them should be resolved.

Regardless of the approach used, configuration serves a single purpose: providing the container with a complete and consistent definition of the system.

2.3.1 Annotation-Based Configuration

In annotation-based configuration, components are defined directly within the source code using metadata annotations.

The container scans the codebase, detects annotated classes and automatically registers them as managed components. Dependencies and configuration details are also expressed through annotations, allowing the container to resolve relationships without external definitions.

This approach reduces explicit configuration and keeps structural information close to the implementation, while still delegating control to the container.

@Repository
public class UserRepository {

    public String findUser() {
        return "User from database";
    }
}

@Service
public class UserService {

    private final UserRepository repository;

    @Autowired
    public UserService(UserRepository repository) {
        this.repository = repository;
    }

    public String getUser() {
        return repository.findUser();
    }
}

@RestController
public class UserController {

    private final UserService service;

    @Autowired
    public UserController(UserService service) {
        this.service = service;
    }

    @GetMapping("/user")
    public String user() {
        return service.getUser();
    }
}

@ComponentScan
        ↓
Detect annotated classes
        ↓
Create beans automatically
        ↓
Resolve dependencies
        ↓
Inject dependencies
        ↓
Application ready

2.3.2 Java-Based Configuration

In Java-based configuration, the structure of the application is defined through dedicated configuration classes.

These classes explicitly declare managed objects and their dependencies using methods. The container processes these definitions and constructs the object graph accordingly.

This approach provides fine-grained control over object creation and is particularly useful when default behavior needs to be customized or when complex wiring logic is required.

public class UserRepository {

    public String findUser() {
        return "User from database";
    }
}

public class UserService {

    private final UserRepository repository;

    public UserService(UserRepository repository) {
        this.repository = repository;
    }

    public String getUser() {
        return repository.findUser();
    }
}

@Configuration
public class AppConfig {

    @Bean
    public UserRepository userRepository() {
        return new UserRepository();
    }

    @Bean
    public UserService userService() {
        return new UserService(userRepository());
    }
}

Read @Configuration class
        ↓
Execute @Bean methods
        ↓
Create objects manually
        ↓
Register beans in container
        ↓
Resolve dependencies

2.3.3 External Configuration

In external or file-based configuration, the structure of the system is defined outside of the application code.

The container reads configuration files and uses them to construct and connect application components. This approach fully separates configuration from implementation, allowing changes to system structure without modifying source code.

Although less common in modern systems, it remains relevant in environments where strict separation between configuration and code is required.

public class UserRepository {

    public String findUser() {
        return "User from database";
    }
}

public class UserService {

    private UserRepository repository;

    public void setRepository(UserRepository repository) {
        this.repository = repository;
    }

    public String getUser() {
        return repository.findUser();
    }
}

<beans>

    <bean id="userRepository"
          class="com.example.UserRepository"/>

    <bean id="userService"
          class="com.example.UserService">

        <property name="repository"
                  ref="userRepository"/>

    </bean>

</beans>

Read XML file
        ↓
Parse bean definitions
        ↓
Create objects
        ↓
Inject dependencies
        ↓
Build object graph

2.4 Bootstrapping Process

Bootstrapping is the process of initializing the IoC Container and preparing it to manage the application.

It represents the transition from a static codebase to a fully operational runtime system. During this phase, the container is created and begins processing configuration metadata.

The container loads component definitions, scans for managed elements, and builds an internal representation of the application structure. It determines how objects should be instantiated, resolves dependencies and prepares the infrastructure required for lifecycle and execution management.

In many cases, the container performs early initialization of certain components during this phase, particularly those required for core system functionality, such as singleton instances or internal services.

Once all definitions are processed and the internal state is fully constructed, the container reaches a stable state. At this point, it is capable of creating objects on demand, injecting dependencies and managing lifecycle transitions.

Bootstrapping is not part of business execution. It is a preparatory phase that establishes the runtime environment in which the application will operate.

The IoC Container is the execution engine of the application.

It transforms a set of class definitions and configuration metadata into a fully connected and managed system. It does not implement business behavior but provides the structural and operational foundation required for all higher-level mechanisms.

Without the container, IoC remains a design principle. With the container, IoC becomes a functioning runtime architecture.

3. Object Management

3.1 Definition of Object Management

Object Management defines how the IoC Container controls the creation, initialization, usage and destruction of application objects (commonly referred to as beans) during runtime.

Once the container has completed the bootstrapping phase and processed configuration metadata, it becomes responsible for managing all application components. These components do not exist independently; they are instantiated, configured and maintained within the container’s execution context.

Object Management is the concrete realization of key IoC principles, particularly controlled lifecycle management and managed object scope. It ensures that object creation is consistent, dependencies are correctly resolved and runtime behavior remains predictable.

Rather than simply instantiating objects, the container applies a structured lifecycle model and enforces scope rules that determine how objects are reused and shared across the system.

3.2 Bean Lifecycle

The Bean Lifecycle describes the sequence of stages that a managed object passes through from its creation to its destruction within the IoC Container.

Object instantiation is only the initial step in a broader lifecycle fully controlled by the container. Before a bean becomes available for use, it must pass through several phases that ensure it is properly configured and operational.

3.2.1 Instantiation

During the instantiation phase, the container creates the object instance.

This is typically performed through constructor invocation or reflection mechanisms. At this stage, the object exists in memory but is not yet fully functional, as its dependencies have not been injected.

3.2.2 Dependency Injection Phase

After instantiation, the container performs dependency injection.

All required dependencies are resolved and injected into the object. This establishes the relationships between components and completes the structural composition of the bean.

At the end of this phase, the object has all required collaborators, but it may still require initialization logic before it can be used safely.

3.2.3 Initialization Phase

In the initialization phase, the container applies any required initialization logic.

This may include invoking lifecycle callbacks, executing initialization methods or applying internal post-processing mechanisms. The goal of this phase is to ensure that the object reaches a valid and stable state.

Only after initialization is complete is the object considered ready for use.

3.2.4 Ready State

Once initialization is completed, the bean enters the ready state.

In this state, the object is fully configured and available for use by other components in the application. It participates in normal application execution and remains in this state for a duration defined by its scope.

3.2.5 Destruction Phase

When the container determines that the bean is no longer needed, it enters the destruction phase.

During this phase, the container executes any cleanup logic associated with the object, such as releasing resources, closing connections or invoking destruction callbacks.

After this process is complete, the object is removed from the container’s management context.

3.3 Bean Scope

Bean Scope defines how the IoC Container controls the creation, reuse and visibility of bean instances within the application.

While the lifecycle describes how an object evolves over time, scope defines how many instances exist and how they are shared.

3.3.1 Singleton Scope

In singleton scope, the container creates a single instance of a bean and shares it across the entire application context.

Every request for that bean returns the same instance. This model is memory-efficient and suitable for stateless or shared components.

3.3.2 Prototype Scope

In prototype scope, the container creates a new instance of the bean each time it is requested.

Unlike singleton beans, prototype instances are not fully managed after creation. The container is responsible for instantiation and dependency injection, but it does not manage the complete lifecycle beyond that point.

3.3.3 Contextual Scopes (Request, Session)

In environments that define execution contexts (such as web applications), additional scopes are available.

A request scope creates a new bean instance for each incoming request, ensuring isolation between requests. A session scope maintains a separate instance for each user session, allowing state to be preserved across multiple interactions.

These scopes align object lifetime with external execution contexts and enable more granular control over resource usage and state management.

Object Management is where IoC becomes operational.

The IoC Container does not merely construct objects; it actively manages their entire existence. Through lifecycle control and scope definition, it ensures that all components are created, configured, reused and destroyed in a consistent and predictable manner.

This allows application code to remain focused on business behavior, while the container guarantees structural integrity and runtime stability.

4. Dependency Injection

(Operational realization of IoC, concrete implementation mechanism)

4.1 DI as Implementation of IoC

Dependency Injection (DI) is the operational mechanism through which Inversion of Control (IoC) is realized in practice.

IoC defines the architectural principle that object creation and dependency management must be delegated to an external system. Dependency Injection is the concrete technique used by the IoC Container to perform that delegation.

Without DI, IoC remains a conceptual model. With DI, the container becomes capable of constructing application components, resolving their dependencies and assembling the complete object graph during runtime.

Under traditional object-oriented design, classes instantiate their collaborators directly. This causes object composition logic to become embedded within business code.

Example of traditional architecture:

public class UserService {

    private UserRepository repository =
            new UserRepository();

}

In this model:

• the class controls dependency creation
• object composition is decentralized
• implementations are tightly coupled
• substitution becomes difficult

Dependency Injection reverses this responsibility.

Instead of creating dependencies internally, application components declare the dependencies they require, while the container provides those dependencies externally.

Example using Spring:

@Service
public class UserService {

    private final UserRepository repository;

    @Autowired
    public UserService(UserRepository repository) {
        this.repository = repository;
    }
}

Here:

• UserService does not create UserRepository
• the dependency is declared
• the container resolves and injects it
• object composition becomes centralized

DI therefore transforms application components from object creators into declarative units that describe required collaborators without controlling how they are obtained.

This introduces a fundamental architectural separation:

Dependency Injection is therefore not an independent architectural concept separate from IoC. It is the primary implementation strategy used by container-based frameworks such as Spring to operationalize IoC at runtime.

4.2 Core Idea of Dependency Injection

The core idea of Dependency Injection is that objects should not construct or locate their own dependencies. Instead, dependencies must be provided externally by the container.

Under DI, components become passive recipients of collaborators.

A component only declares:

• what it requires
• which abstractions it depends on
• which collaborators are necessary for operation

The container assumes responsibility for:

• locating dependencies
• constructing objects
• resolving relationships
• injecting the correct instances

This model shifts the system from imperative composition to declarative composition.

Traditional model:

Class → creates dependencies

Dependency Injection model:

Container → injects dependencies into class

This inversion produces several architectural benefits.

Reduced Coupling

Classes no longer depend on concrete implementations.

Example:

public class UserService {

    private final UserRepository repository;

    public UserService(UserRepository repository) {
        this.repository = repository;
    }
}

The service depends on the abstraction of a collaborator, not on its creation process.

Centralized Composition

All object relationships are controlled by the container.

The complete application structure becomes externally manageable and deterministic.

Improved Testability

Dependencies can easily be replaced with mocks or alternative implementations.

Example:

UserRepository mockRepository =
        Mockito.mock(UserRepository.class);

UserService service =
        new UserService(mockRepository);

Because dependencies are injected externally, the service can be tested in isolation.

Lifecycle Consistency

The container controls:

• instantiation
• initialization
• reuse
• destruction
• scope behavior

Application code remains focused exclusively on domain logic.

Dependency Injection therefore represents a structural composition model in which application components are assembled externally by the container rather than internally by application code.

4.3 Forms of Dependency Injection

Dependency Injection can be implemented through multiple injection strategies.

The IoC Container supports several mechanisms for supplying dependencies to managed objects.

The three primary forms are:

• Constructor Injection
• Setter Injection
• Field Injection

Although all three achieve the same goal, they differ in:

• lifecycle semantics
• immutability guarantees
• visibility of dependencies
• architectural safety

4.3.1 Constructor Injection

Constructor Injection provides dependencies through the class constructor.

The container invokes the constructor and supplies all required collaborators during object creation.

Example:

@Service
public class UserService {

    private final UserRepository repository;

    @Autowired
    public UserService(UserRepository repository) {
        this.repository = repository;
    }

    public String getUser() {
        return repository.findUser();
    }
}

Execution process:

Container creates UserRepository
        ↓
Container invokes UserService constructor
        ↓
Dependency injected during instantiation
        ↓
Fully initialized immutable object

Mandatory Dependencies

A dependency required in the constructor becomes mandatory.

The object cannot exist in an invalid state.

Immutability

Dependencies can be declared final.

private final UserRepository repository;

This guarantees that injected collaborators cannot change after construction.

Explicit Object Structure

All required collaborators are visible directly in the constructor signature.

This improves readability and architectural clarity.

Preferred Strategy in Spring

Constructor Injection is generally considered the recommended approach in modern Spring applications because it promotes:

• immutability
• explicit dependencies
• safer initialization
• easier testing

4.3.2 Setter Injection

Setter Injection provides dependencies through setter methods after object creation.

The container:

1. creates the object,
2. then invokes setter methods to inject collaborators.

Example:

@Service
public class UserService {

    private UserRepository repository;

    @Autowired
    public void setRepository(UserRepository repository) {
        this.repository = repository;
    }

    public String getUser() {
        return repository.findUser();
    }
}

Execution process:

Container instantiates object
        ↓
Object exists without dependency
        ↓
Container invokes setter method
        ↓
Dependency assigned after creation

Characteristics

Optional Dependencies

Setter Injection is useful when dependencies are optional rather than mandatory.

Mutable Structure

Dependencies can be modified after object creation.

This introduces more flexibility but reduces immutability guarantees.

Two-Phase Initialization

The object exists temporarily in a partially initialized state before dependency injection completes.

Historical Usage

Setter Injection was more common in older Spring applications and XML-based configurations.

Modern systems typically prefer Constructor Injection except for optional collaborators.

4.3.3 Field Injection

Field Injection injects dependencies directly into object fields using reflection.

Example:

@Service
public class UserService {

    @Autowired
    private UserRepository repository;

    public String getUser() {
        return repository.findUser();
    }
}

Execution process:

Container creates object
        ↓
Container accesses private field
        ↓
Dependency injected via reflection

Characteristics

Minimal Boilerplate

Field Injection requires less code.

No constructor or setter is necessary.

Hidden Dependencies

Dependencies are not explicitly visible in constructors.

This reduces transparency of object requirements.

Reduced Testability

Testing becomes more difficult because dependencies cannot easily be supplied manually.

Reflection-Based Injection

The container must bypass encapsulation through reflection mechanisms.

Discouraged in Modern Spring Design

Although widely used historically, Field Injection is generally discouraged in modern Spring architecture because it:

• hides dependencies
• reduces immutability
• complicates testing
• weakens explicit object design

4.4 Dependency Resolution Process

Dependency Resolution is the process through which the IoC Container determines which objects must be injected into a component.

This process occurs during bean creation and is fully managed by the container.

The resolution pipeline typically follows these stages:

1. Bean Definition Discovery

The container identifies managed components through:

• annotations
• configuration classes
• external configuration metadata

Example:

@Service
public class UserService

2. Dependency Analysis

The container analyzes:

• constructors
• fields
• setter methods
• injection metadata

It determines which dependencies are required.

Example:

public UserService(UserRepository repository)

Required dependency:

• UserRepository

3. Bean Lookup

The container searches its internal registry for a compatible bean.

Resolution may occur:

• by type
• by qualifier
• by bean name
• by primary designation

4. Dependency Construction

If the dependency does not yet exist, the container recursively creates it.

This process may trigger additional dependency chains.

Example:

UserController
    ↓
UserService
    ↓
UserRepository

5. Injection

Once resolved, the dependency is injected into the target object.

6. Initialization Completion

After all dependencies are injected:

• initialization callbacks execute
• post-processors run
• the bean becomes operational.

The Dependency Resolution Process therefore represents the dynamic assembly phase in which the container builds the complete runtime object graph.

4.5 Relationship with IoC Container

Dependency Injection cannot exist independently from the IoC Container.

The container is the execution engine that makes DI possible.

DI itself is not responsible for:

• object creation
• lifecycle management
• scope handling
• proxy generation
• runtime interception

Those responsibilities belong to the container.

The relationship can therefore be understood as follows:

The IoC Container performs DI as part of its broader object management responsibilities.

Execution flow:

Configuration Metadata
        ↓
IoC Container Bootstrapping
        ↓
Bean Discovery
        ↓
Object Instantiation
        ↓
Dependency Resolution
        ↓
Dependency Injection
        ↓
Initialization
        ↓
Ready State

Dependency Injection is therefore one phase inside the larger container-managed lifecycle.

Without the container:

• dependency injection cannot occur automatically
• object graphs cannot be centrally managed
• runtime composition becomes fragmented

The IoC Container transforms Dependency Injection from a simple coding technique into a complete runtime composition model capable of supporting large-scale modular architectures.

5. Aspect-Oriented Programming (AOP)

(Behavioral extension layer over the container-managed runtime model)

5.1 Definition of AOP

Aspect-Oriented Programming (AOP) is a programming paradigm that introduces a structured mechanism for modularizing behaviors that affect multiple parts of an application simultaneously.

In traditional object-oriented design, application logic is primarily organized around business entities and services. However, certain types of behavior do not belong exclusively to a single component. Instead, they appear repeatedly across multiple layers of the system.

Examples include:

• transaction management
• logging
• security validation
• auditing
• caching
• monitoring
• performance measurement
• exception handling

These concerns are commonly referred to as cross-cutting concerns because they cut across the primary object model of the application.

Without AOP, these behaviors become duplicated throughout the codebase.

Example without AOP:

@Service
public class UserService {

    public void createUser() {

        log.info("Starting transaction");

        try {

            // business logic

            log.info("Commit transaction");

        } catch (Exception e) {

            log.error("Rollback transaction");
        }
    }
}

In this model:

• business logic and infrastructure logic become mixed
• duplication increases
• maintenance becomes difficult
• behavioral consistency is harder to enforce

AOP introduces a different execution model.

Instead of embedding infrastructure behavior directly into application code, the system externalizes these behaviors into independent modules called aspects.

The container then applies these aspects dynamically during runtime execution.

Example using Spring AOP:

@Aspect
@Component
public class LoggingAspect {

    @Before("execution(* com.example.service.*.*(..))")
    public void logBefore() {

        System.out.println("Method execution intercepted");
    }
}

Here:

• logging behavior is separated from business logic
• the aspect defines where interception occurs
• the container applies the behavior automatically
• business components remain focused on domain functionality

AOP therefore extends the IoC model from structural management into behavioral management.

IoC externalizes:

• object creation
• dependency wiring
• lifecycle management

AOP externalizes:

• runtime behavioral concerns
• execution interception
• infrastructural processing

This introduces a second major architectural separation:

• Structure → managed by the IoC Container
• Behavior → dynamically enhanced through AOP

Aspect-Oriented Programming is therefore not a replacement for object-oriented programming, but an extension layer that complements it by modularizing behaviors that cannot be cleanly encapsulated through traditional class hierarchies alone.

5.2 Separation of Cross-Cutting Concerns

The central objective of AOP is the separation of cross-cutting concerns from core business logic.

A cross-cutting concern is a behavior that:

• affects multiple components
• is not tied to a single business responsibility
• must be applied consistently throughout the system

In layered applications, these concerns often appear repeatedly.

Example:

@Service
public class PaymentService {

    public void processPayment() {

        securityCheck();

        startTransaction();

        logRequest();

        // business logic

        commitTransaction();
    }
}

The actual business operation becomes surrounded by infrastructural behavior.

This creates several architectural problems.

Code Duplication
The same infrastructure logic appears across multiple services.

Tight Coupling
Business components become dependent on technical infrastructure.

Reduced Clarity
Core domain behavior becomes obscured by repetitive operational logic.

Maintenance Complexity
Changing infrastructure policies requires modifications across many classes.

AOP solves this problem by extracting these behaviors into centralized aspects.

Example:

@Aspect
@Component
public class TransactionAspect {

    @Around("@annotation(Transactional)")
    public Object manageTransaction(
            ProceedingJoinPoint joinPoint) throws Throwable {

        try {

            startTransaction();

            Object result = joinPoint.proceed();

            commitTransaction();

            return result;

        } catch (Exception e) {

            rollbackTransaction();
            throw e;
        }
    }
}

Business logic becomes simplified:

@Service
public class PaymentService {

    @Transactional
    public void processPayment() {

        // pure business logic
    }
}

The business component no longer controls:

• transaction boundaries
• logging
• security checks
• monitoring logic

Those concerns are externalized into reusable behavioral modules managed by the container.

This produces a clean architectural division:

• Core concerns → business/domain behavior
• Cross-cutting concerns → infrastructural runtime behavior

The separation of cross-cutting concerns is therefore the primary architectural motivation behind AOP.

5.3 Interception Mechanism

AOP operates through an interception mechanism.

The fundamental idea is that method execution can be intercepted dynamically before, during or after invocation.

Instead of invoking a target object directly, the container introduces an intermediate execution layer capable of:

• observing method calls
• injecting additional behavior
• modifying execution flow
• handling exceptions
• controlling method continuation

Conceptually:

Caller
   ↓
Proxy / Interceptor
   ↓
Target Object

The interception layer acts as a runtime behavioral gateway.

When a method call occurs:

1. the proxy intercepts the invocation
2. the aspect logic executes
3. the original method may continue
4. additional post-processing may occur

Example:

@Aspect
@Component
public class LoggingAspect {

    @Before("execution(* com.example.service.*.*(..))")
    public void beforeExecution() {

        System.out.println("Before method execution");
    }
}

Execution flow:

Client invokes method
        ↓
Proxy intercepts invocation
        ↓
@Before advice executes
        ↓
Target method executes
        ↓
Result returned

Interception enables:

• transparent behavioral enhancement
• centralized runtime policies
• dynamic execution control
• reusable infrastructure logic

Importantly, the target object is often unaware that interception is occurring.

From the perspective of the application component:

• execution appears normal
• no infrastructure code is required
• interception remains externalized

This transparency is one of the defining characteristics of AOP-based runtime systems.

5.4 Proxy-Based Execution Model

In Spring AOP, interception is implemented primarily through proxies.

A proxy is a runtime-generated object that wraps the original target object and intercepts method invocations before delegating execution to the real component.

Instead of exposing the original bean directly, the container exposes the proxy.

Conceptual model:

Client
   ↓
Proxy Object
   ↓
Target Bean

The proxy becomes the externally visible object inside the container.

When a method is called:

1. the proxy receives the invocation
2. matching aspects execute
3. the target method is invoked
4. post-processing logic executes
5. the result returns to the caller

Example:

@Service
public class UserService {

    @Transactional
    public void registerUser() {

        // business logic
    }
}

Runtime behavior:

Client calls registerUser()
        ↓
Transactional proxy intercepts
        ↓
Transaction starts
        ↓
Target method executes
        ↓
Transaction commits
        ↓
Result returned

The target class itself contains no transaction management code.

Spring commonly uses two proxy strategies.

JDK Dynamic Proxies

• used when interfaces are available
• proxy implements the same interfaces as the target object

CGLIB Proxies

• used when no interface exists
• proxy subclasses the concrete class dynamically

This model allows the container to enhance behavior without modifying the original source code.

Proxy-based execution is therefore the operational foundation of Spring AOP.

5.5 Aspects

An aspect is a modular unit that encapsulates cross-cutting behavior.

It defines:

• where behavioral interception occurs
• what additional behavior executes
• how execution flow is modified

An aspect combines:

• Pointcuts
• Advice
• Weaving rules

Example:

@Aspect
@Component
public class SecurityAspect {

    @Before(
      "execution(* com.example.service.*.*(..))"
    )
    public void validateSecurity() {

        System.out.println("Security validation");
    }
}

The aspect itself does not belong to business logic.
Instead, it defines behavioral policies applied externally by the container.

Aspects therefore function as reusable runtime behavior modules.

5.5.1 Pointcut

A pointcut defines where interception should occur.

It identifies:

• methods
• classes
• packages
• annotations
• execution patterns

that should be intercepted by the aspect.

Example:

execution(* com.example.service.*.*(..))

Meaning:

• any method
• inside the service package
• regardless of return type
• regardless of parameters

Pointcuts act as behavioral selectors.

Without pointcuts:

• the container would not know where to apply aspects
• interception would become uncontrolled

Example using annotations:

@Pointcut("@annotation(Transactional)")
public void transactionalMethods() {}

This selects all methods annotated with @Transactional.

Pointcuts therefore define the structural targeting rules for runtime interception.

5.5.2 Advice

Advice defines the behavior executed when a pointcut matches a method invocation.

It represents the actual logic applied during interception.

Spring supports multiple advice types.

Before Advice

Executes before the target method.

@Before("execution(* service.*.*(..))")
public void before() {
    System.out.println("Before execution");
}

After Advice

Executes after method completion.

@After("execution(* service.*.*(..))")
public void after() {
    System.out.println("After execution");
}

After Returning Advice

Executes only if the method completes successfully.

@AfterReturning(
    pointcut = "execution(* service.*.*(..))",
    returning = "result"
)
public void afterReturning(Object result) {
}

After Throwing Advice

Executes when an exception occurs.

@AfterThrowing(
    pointcut = "execution(* service.*.*(..))",
    throwing = "ex"
)
public void handleException(Exception ex) {
}

Around Advice

Provides complete control over execution flow.

@Around("execution(* service.*.*(..))")
public Object around(
        ProceedingJoinPoint joinPoint)
        throws Throwable {

    System.out.println("Before");

    Object result = joinPoint.proceed();

    System.out.println("After");

    return result;
}

@Around advice is the most powerful form because it can:

• continue execution
• block execution
• modify arguments
• alter return values
• manage transactions
• measure performance

Advice therefore defines the runtime behavior injected into the execution pipeline.

5.5.3 Weaving

Weaving is the process of combining aspects with application code.

It is the mechanism through which the system integrates:

• target objects
• pointcuts
• advice
• interception logic

into a unified execution model.

Conceptually:

Target Object
      +
Aspect Definition
      ↓
Weaved Runtime Object

Spring performs weaving primarily at runtime through proxy creation.

Execution stages:

Bean creation
        ↓
Aspect detection
        ↓
Proxy generation
        ↓
Advice binding
        ↓
Runtime interception enabled

Other AOP frameworks may support:

• compile-time weaving
• bytecode weaving
• load-time weaving

However, Spring AOP focuses mainly on lightweight proxy-based runtime weaving.

Weaving therefore represents the integration phase where behavioral enhancement becomes operational.

5.6 Execution Flow with AOP

The AOP execution model introduces an additional behavioral layer into the normal application execution pipeline.

Standard execution without AOP:

Client
   ↓
Target Object
   ↓
Method Execution

Execution with AOP:

Client
   ↓
Proxy
   ↓
Aspect Interception
   ↓
Advice Execution
   ↓
Target Method
   ↓
Post-Processing
   ↓
Return Result

Complete runtime example:

HTTP Request
        ↓
Controller
        ↓
AOP Proxy
        ↓
Transaction Aspect
        ↓
Security Aspect
        ↓
Logging Aspect
        ↓
Business Method
        ↓
Commit Transaction
        ↓
Return Response

This execution model allows multiple infrastructural behaviors to be layered dynamically around the same business operation without modifying application code.

AOP therefore transforms runtime execution into a composable behavioral pipeline.

5.7 Relationship with IoC Container

AOP depends directly on the IoC Container.

Without the container:

• aspects cannot be discovered automatically
• proxies cannot be generated centrally
• interception cannot be coordinated
• runtime weaving cannot occur transparently

The IoC Container provides:

• bean lifecycle management
• proxy creation
• aspect registration
• dependency injection
• runtime object substitution

AOP operates as an extension layer built on top of container-managed object management.

Execution relationship:

Configuration Metadata
        ↓
IoC Container Bootstrapping
        ↓
Bean Discovery
        ↓
Aspect Detection
        ↓
Proxy Generation
        ↓
Dependency Injection
        ↓
Runtime Interception Enabled
        ↓
Application Ready

The container determines:

• which beans require proxies
• which aspects apply
• how interception chains are assembled
• how runtime behavior is enhanced

Importantly, proxied objects remain fully managed beans inside the container.

This means:

• AOP integrates naturally with Dependency Injection
• transactional behavior can be injected transparently
• aspects themselves can receive dependencies
• runtime behavior becomes centrally orchestrated

Aspect-Oriented Programming is therefore not an isolated mechanism separate from IoC.
It is a behavioral extension of the container-managed runtime architecture.

IoC manages:

• structure
• object composition
• lifecycle

AOP manages:

• runtime behavior
• execution interception
• infrastructural processing

Together, they form the structural and behavioral foundation of modern Spring-based enterprise architectures.

6. Transaction Management

Transaction Management is the infrastructure mechanism responsible for guaranteeing consistency during the execution of business operations that interact with persistent resources. In enterprise applications, a single operation often involves multiple database actions that must behave as one atomic unit of work. If one operation fails while others succeed, the application may enter an inconsistent state. Transaction management solves this problem by ensuring that all operations are either committed successfully or completely reverted through rollback. In Spring-based architectures, this responsibility is externalized from business logic and managed by the container through declarative configuration and runtime interception.

6.1 Definition of Transaction Management

A transaction defines a protected execution boundary around a business operation. All actions executed inside this boundary belong to the same unit of work and remain coordinated until execution finishes. If the operation completes successfully, the transaction is committed and all changes become permanent. If an exception occurs, the transaction is rolled back and the previous consistent state is restored. This model guarantees atomicity, consistency and reliability during runtime execution without forcing the application to manage low-level persistence infrastructure manually.

6.2 Transactions as Aspects (AOP-Based Model)

In Spring, transaction management is implemented primarily through Aspect-Oriented Programming (AOP). Instead of embedding transaction control directly inside business methods, transactional behavior is applied externally through proxies and interceptors managed by the container. The @Transactional annotation acts as metadata that marks a method for transactional interception. When the method is invoked, the proxy intercepts execution, opens a transaction, delegates execution to the target method and finally decides whether to commit or rollback depending on the execution result. This approach keeps business logic isolated from infrastructural concerns and allows transaction policies to be centralized and reusable across the entire application.

6.3 Transaction Interception Flow

When a transactional method is called, execution first passes through a container-managed proxy rather than directly reaching the target object. The proxy detects the transactional metadata and activates the transaction interceptor. The interceptor requests a transaction from the transaction manager, initializes the transactional context and then invokes the business method inside that boundary. After execution completes, the interceptor evaluates the result. Successful execution leads to commit, while exceptions trigger rollback. Finally, all transactional resources are released and control returns to the caller. This entire process occurs transparently at runtime without explicit transaction management inside application code.

6.4 Transaction Lifecycle

The transaction lifecycle represents the sequence of stages through which a transaction passes during execution. Once a transactional method is intercepted, the transaction manager creates the transactional context and binds the necessary persistence resources to the current execution thread. The business logic then executes within the active transaction boundary while all modifications remain temporary until completion. If execution finishes correctly, the transaction enters the commit phase and all changes are permanently persisted. If an error occurs, the transaction transitions into rollback, reverting all operations executed during the transaction in order to preserve consistency and prevent partial updates.

6.4.1 Transaction Start

During the start phase, the transaction manager initializes the transactional context, obtains the required persistence resources and establishes the execution boundary that will contain the business operation.

6.4.2 Execution Phase

During the execution phase, the target business method runs inside the active transactional boundary previously created by the transaction manager. All persistence operations executed during this stage become part of the same logical unit of work and remain coordinated until the transaction reaches its final state. Changes performed against the database are not permanently persisted immediately, since they still depend on the final outcome of the transaction. If execution completes successfully, the transaction may proceed to the commit phase; otherwise, any runtime failure or exception may trigger a rollback operation that cancels all modifications executed during the transaction scope. This phase represents the core operational stage of the transactional lifecycle because it is where the actual business logic executes under transactional protection.

6.4.3 Commit Phase

If the business operation completes successfully, the transaction enters the commit phase. During this stage, the transaction manager permanently persists all changes executed within the transactional boundary and synchronizes the final state with the underlying database. Once the commit operation is completed, the transaction is considered successful and the associated resources are released. This phase guarantees that all operations executed during the transaction become permanently visible and consistent from the perspective of the system.

6.4.4 Rollback Phase

If an exception occurs during execution, the transaction enters the rollback phase. In this stage, the transaction manager cancels all operations performed inside the transactional context and restores the previous consistent state of the system. Rollback prevents partially completed operations from being permanently persisted and guarantees atomic execution behavior. This mechanism is essential for maintaining reliability and consistency during runtime failures, especially when multiple persistence operations are executed as part of the same business process.

6.5 Declarative Transaction Model

In Spring-based architectures, transaction management is commonly implemented through a declarative model based on metadata annotations such as @Transactional. Instead of manually controlling transaction boundaries inside application code, developers declare transactional behavior at the method or class level while the container manages the underlying infrastructure automatically. This approach simplifies application design by separating business logic from persistence and transaction coordination concerns. The declarative model also centralizes transaction policies and integrates directly with the AOP interception system responsible for applying transactional behavior during runtime execution.

6.6 Relationship with IoC and Dependency Injection

Transaction Management is deeply integrated with the IoC Container and the Dependency Injection model. The container creates and manages transactional proxies, injects the required infrastructural dependencies and coordinates the runtime interception process used to apply transaction behavior dynamically. Dependency Injection allows business components to remain independent from transaction APIs and persistence infrastructure, while IoC provides the lifecycle and proxy management required for transactional execution. Together, IoC, Dependency Injection and AOP form the infrastructural foundation that enables transparent and container-managed transaction coordination in modern enterprise applications.

7. Persistence Integration

Persistence Integration is the infrastructural layer responsible for connecting the application runtime with persistent storage systems such as relational databases. In enterprise architectures, business operations constantly require the creation, retrieval, modification and deletion of persistent data. Instead of allowing business components to interact directly with low-level database APIs, modern frameworks introduce an abstraction layer that centralizes persistence access, resource management and transaction coordination. In Spring-based systems, persistence integration is deeply connected with the IoC Container, Dependency Injection, Transaction Management and the ORM infrastructure, allowing persistence operations to be executed transparently inside the container-managed runtime model.

7.1 Definition of Persistence Integration

Persistence Integration is the process through which the runtime environment coordinates application components, persistence frameworks and database resources in order to provide consistent and abstracted access to persistent data. Its objective is to isolate business logic from low-level persistence concerns such as connection management, SQL execution, transaction synchronization and object-relational mapping.

In traditional applications, persistence logic was frequently embedded directly inside business components, forcing developers to manually manage JDBC connections, SQL statements and resource cleanup. This approach produced tightly coupled architectures where business logic became dependent on infrastructural APIs and persistence implementation details.

Modern container-managed architectures externalize these responsibilities into dedicated persistence layers integrated with the runtime container. Instead of interacting directly with database infrastructure, business components operate through repositories, entity managers and persistence contexts managed by the framework itself. This separation improves maintainability, scalability and consistency while reducing boilerplate infrastructure code.

Persistence Integration therefore acts as the bridge between the object-oriented domain model and the underlying persistent storage system, enabling enterprise applications to manipulate persistent state while remaining structurally independent from database implementation details.

7.2 Persistence Components

Persistence Integration is composed of multiple infrastructural components that collaborate during runtime execution. Each component has a specialized responsibility inside the persistence architecture and together they form the persistence execution pipeline used by the container.

The Data Source provides physical connectivity with the database and manages connection allocation during execution. The Entity Manager or ORM Session controls the persistence context and coordinates entity state transitions during runtime operations. Repositories and Data Access Layers provide abstraction over persistence access by exposing simplified interfaces used by business services to interact with persistent data without directly manipulating low-level persistence APIs.

These components are fully integrated into the IoC Container and are typically injected automatically into business components through Dependency Injection.

7.2.1 Data Source

The Data Source represents the infrastructural component responsible for managing physical database connectivity. Instead of manually opening and closing JDBC connections inside application code, enterprise frameworks centralize connection management through a container-managed Data Source.

The Data Source maintains connection pools, allocates connections during execution and releases them once transactional operations complete. This model improves performance, scalability and resource efficiency because connections can be reused across multiple requests instead of being constantly recreated.

In Spring-based architectures, the Data Source is generally configured as a managed bean inside the container and becomes the foundational resource used by the persistence infrastructure, transaction manager and ORM framework during runtime execution.

The business layer remains completely isolated from direct connection handling, allowing persistence operations to occur transparently through the container-managed execution pipeline.

7.2.2 Entity Manager / Session

The Entity Manager, or Session in Hibernate terminology, is the central runtime component responsible for managing persistent entities inside the persistence context. It acts as the intermediary between the application domain model and the database layer.

When entities are loaded, modified or removed during execution, the Entity Manager tracks their state transitions and synchronizes those changes with the database when the transaction reaches the commit phase. This mechanism allows developers to manipulate ordinary Java objects while the persistence infrastructure automatically coordinates SQL generation and synchronization internally.

The Entity Manager also controls the lifecycle of managed entities, including entity retrieval, dirty checking, caching and persistence synchronization. Instead of writing explicit SQL for every operation, developers interact with domain entities while the ORM framework translates object state transitions into database operations during runtime execution.

This model significantly reduces infrastructural complexity and enables the persistence layer to remain integrated with container-managed transactions and transactional synchronization.

Example: Entity Management and Automatic Persistence Synchronization

@Entity
public class User {

    @Id
    private Long id;

    private String name;
}

@Transactional
public void updateUser() {

    User user = entityManager.find(User.class, 1L);

    user.setName("John Updated");
}

After the entity is loaded through the Entity Manager, it becomes managed by the Persistence Context. Any modification performed on the entity is automatically tracked by the ORM framework through dirty checking. When the transaction reaches the commit phase, Hibernate synchronizes the updated entity state with the database by generating the corresponding SQL UPDATE statement automatically, without requiring explicit SQL manipulation inside application code.

7.2.3 Repositories / Data Access Layer

Repositories and Data Access Layers provide the abstraction layer used by business services to access persistent data. Their purpose is to isolate persistence operations from business logic by encapsulating data retrieval and storage responsibilities into dedicated components.

Instead of embedding persistence queries directly inside service classes, enterprise applications centralize persistence access through repositories that expose domain-oriented operations such as entity retrieval, persistence and deletion. This separation improves architectural clarity and prevents business components from becoming dependent on persistence implementation details.

In Spring Data architectures, repositories are commonly declared as interfaces managed automatically by the container. The framework dynamically generates the underlying persistence implementation during runtime, allowing developers to work with high-level persistence abstractions instead of manually implementing repetitive database access code.

This repository-based model reinforces the separation between business behavior and infrastructural persistence concerns while maintaining consistency across the application architecture.

Example: Repository Abstraction with Spring Data JPA

@Repository
public interface UserRepository
        extends JpaRepository<User, Long> {

}

@Service
public class UserService {

    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {

        this.userRepository = userRepository;
    }

    public User loadUser(Long id) {

        return userRepository.findById(id)
                .orElse(null);
    }
}

The service layer interacts only with the repository abstraction and remains completely independent from JDBC APIs, SQL statements and persistence implementation details. Spring Data JPA dynamically generates the repository implementation during runtime, allowing the application to access persistent data through high-level domain-oriented operations instead of manually implementing database access logic.

7.3 Persistence Context

The Persistence Context represents the runtime environment in which persistent entities are managed and tracked during execution. It acts as an internal workspace maintained by the Entity Manager where entity instances remain synchronized with the current transactional state.

When an entity is loaded into the persistence context, it becomes managed by the ORM infrastructure. Any modifications performed on that entity are automatically detected and coordinated internally by the persistence framework. Instead of immediately synchronizing changes with the database, modifications remain temporarily stored inside the persistence context until the transaction reaches completion.

This mechanism enables automatic dirty checking, identity management and transactional synchronization. Multiple operations executed during the same transaction therefore interact with a consistent in-memory representation of persistent entities before final synchronization occurs.

The Persistence Context is tightly integrated with Transaction Management because its lifecycle is commonly bound to the active transaction scope managed by the container.

7.4 Integration with Container-Managed Transactions

Persistence Integration is deeply connected with the container-managed transaction system. During runtime execution, persistence operations execute inside transactional boundaries coordinated by the transaction manager and the AOP interception infrastructure.

When a transactional method begins execution, the container creates the transactional context and associates the persistence resources required during the operation. The Entity Manager, persistence context and database connection become synchronized with the active transaction, ensuring that all persistence operations belong to the same consistent unit of work.

As business logic executes, the persistence infrastructure tracks entity modifications while the transaction remains active. If execution completes successfully, the transaction manager coordinates the commit operation and the persistence context synchronizes all pending changes with the database. If an exception occurs, rollback cancels the transaction and discards all pending modifications in order to preserve consistency.

This integration between Persistence Integration and Transaction Management allows enterprise applications to execute complex persistence operations while remaining isolated from low-level synchronization and transaction coordination concerns.

7.5 Execution Flow with Persistence

The persistence execution flow begins when a business service invokes a repository or persistence operation during runtime execution. Instead of interacting directly with the database, the request passes through the container-managed persistence infrastructure.

The repository delegates the operation to the Entity Manager, which interacts with the persistence context responsible for managing entity state during the active transaction. The persistence provider then translates object-oriented operations into SQL statements executed against the database through the Data Source connection infrastructure.

Throughout execution, the persistence context tracks entity modifications and maintains synchronization with the transactional boundary. Once execution completes, the transaction manager determines whether the operation should be committed or rolled back depending on the execution outcome.

This execution pipeline allows business logic to remain focused on domain behavior while the container transparently coordinates persistence synchronization, SQL generation, resource management and transactional consistency internally.

7.6 Abstraction of Data Access

One of the primary objectives of Persistence Integration is the abstraction of data access infrastructure from business logic. Enterprise applications should not depend directly on JDBC APIs, SQL statements or database-specific implementations because doing so introduces tight coupling between the application domain and the persistence technology.

Persistence abstraction allows developers to work with domain entities, repositories and business-oriented operations instead of low-level persistence mechanisms. The framework internally translates those operations into database interactions while maintaining transactional consistency and persistence synchronization transparently.

This abstraction model improves portability, maintainability and architectural separation because business components remain independent from persistence implementation details. Changes in database providers, ORM frameworks or persistence configurations can therefore occur with minimal impact on the business layer.

Persistence Integration consequently represents the persistence coordination layer of the container-managed runtime architecture. Together with IoC, Dependency Injection, AOP and Transaction Management, it forms part of the infrastructural foundation that enables scalable, maintainable and consistent enterprise application execution.

8. Runtime Execution Model

(Integration of all previous layers into a unified execution pipeline)

8.1 Definition of Runtime Execution Model

The Runtime Execution Model represents the coordinated execution architecture through which all infrastructural layers of the framework collaborate during application runtime. Instead of operating as isolated mechanisms, the IoC Container, Dependency Injection, Aspect-Oriented Programming, Transaction Management and Persistence Integration form a unified execution pipeline responsible for managing object creation, dependency coordination, runtime interception, transactional consistency and persistence synchronization.

In container-managed enterprise architectures, application execution is not limited to direct method invocation between objects. Every operation executes inside an infrastructural environment controlled by the runtime container, where multiple framework services participate transparently during execution. Business components therefore interact primarily with the domain model while the container orchestrates infrastructural behavior automatically behind the execution flow.

The Runtime Execution Model externalizes infrastructural responsibilities from application code and centralizes them inside the container-managed runtime environment. This approach enables enterprise systems to maintain consistency, scalability, modularity and deterministic execution behavior while reducing coupling between business logic and infrastructural concerns.

The runtime model consequently acts as the operational foundation that integrates all previous architectural layers into a single coordinated execution system.

8.2 Structural Phase vs Runtime Phase

Container-managed architectures operate through two complementary execution dimensions: the structural phase and the runtime phase. Although both belong to the same infrastructural system, each phase has different responsibilities inside the application lifecycle.

The structural phase occurs during container initialization and application bootstrapping. During this stage, the IoC Container scans configuration metadata, discovers components, creates bean definitions, resolves dependencies and builds the internal object graph required by the application. Proxy generation, dependency wiring and infrastructural configuration also occur during this initialization process before business execution begins.

At this stage, the framework prepares the execution environment but business operations have not yet started. The container therefore constructs the structural architecture required for runtime execution.

The runtime phase begins once the application starts processing business operations and method invocations. During execution, proxies intercept calls, aspects execute infrastructural behavior, transactions are coordinated, persistence contexts become active and runtime synchronization mechanisms manage consistency across the application.

While the structural phase defines how the application is assembled, the runtime phase defines how the application behaves during execution.

This distinction is fundamental because modern enterprise frameworks separate architectural construction from operational execution. The container first builds the execution environment and later orchestrates runtime behavior dynamically through the infrastructural layers previously configured during initialization.

8.3 End-to-End Execution Flow

The end-to-end execution flow represents the complete runtime path followed by a business request as it traverses the container-managed infrastructure. Instead of executing directly between application objects, requests move through multiple infrastructural layers coordinated transparently by the runtime environment.

Execution commonly begins when an external client invokes an application endpoint. The request first reaches a container-managed component that may already be wrapped by runtime-generated proxies responsible for infrastructural interception.

If Aspect-Oriented Programming features such as transaction management are active, the proxy intercepts execution before the target business method executes. Transactional boundaries are initialized, persistence resources are associated with the execution context and the runtime environment becomes synchronized with the active transaction scope.

The business method then executes while interacting with repositories, persistence abstractions and domain entities. Persistence operations are delegated to the Entity Manager and coordinated internally through the Persistence Context, where entity state transitions remain synchronized during the active transaction.

As execution completes, the transaction manager evaluates the execution outcome. Successful execution triggers commit and persistence synchronization with the database, while exceptions trigger rollback and cancellation of pending modifications.

Finally, infrastructural resources are released, the execution context is finalized and control returns to the client.

This entire execution pipeline occurs transparently through coordinated interaction between the container, proxies, transactional infrastructure and persistence mechanisms without requiring explicit infrastructural coordination inside business code.

8.4 Unified Execution Pipeline

The Runtime Execution Model unifies all infrastructural layers into a coordinated execution pipeline where each architectural component contributes a specialized responsibility during runtime execution. Rather than functioning independently, the container-managed infrastructure behaves as an integrated operational system.

The IoC Container provides object lifecycle management and establishes the structural foundation of the application. Dependency Injection connects application components and supplies infrastructural dependencies required during execution. Aspect-Oriented Programming introduces runtime interception capabilities that allow infrastructural behavior to execute transparently around business operations.

Transaction Management coordinates execution consistency by defining transactional boundaries, synchronizing persistence operations and controlling commit or rollback behavior during execution. Persistence Integration manages entity synchronization, persistence contexts, repository abstraction and communication with the underlying database infrastructure.

Together, these layers form a continuous execution pipeline where business operations move through multiple infrastructural stages before execution completes. The runtime environment therefore becomes responsible not only for executing business logic, but also for coordinating consistency, persistence synchronization, infrastructural interception and resource management automatically.

The unified execution pipeline consequently transforms the framework into a fully coordinated runtime orchestration system rather than a simple dependency management mechanism.

8.4.1 IoC Container

The IoC Container acts as the structural core of the Runtime Execution Model. It is responsible for discovering components, creating managed objects, controlling bean lifecycles and maintaining the internal dependency graph required by the application.

During application initialization, the container analyzes configuration metadata, registers bean definitions and prepares the infrastructural environment used during runtime execution. The container also manages proxy creation and integrates infrastructural services such as transaction management and persistence coordination into the execution architecture.

Without the IoC Container, the runtime infrastructure would not have a centralized mechanism capable of coordinating object management, lifecycle control and infrastructural orchestration consistently across the application.

8.4.2 Dependency Injection

Dependency Injection provides the connectivity mechanism that links all managed components inside the runtime architecture. Instead of allowing components to manually create infrastructural dependencies, the container injects required collaborators automatically during initialization.

This model enables business services to remain structurally independent from infrastructural implementations such as repositories, transaction managers or persistence providers. Components therefore depend on abstractions rather than directly controlling object creation or infrastructural coordination.

Dependency Injection also enables the runtime infrastructure to dynamically replace implementations, inject proxies and coordinate execution behavior transparently without modifying business logic.

8.4.3 AOP

Aspect-Oriented Programming introduces runtime behavioral interception into the execution pipeline. Through proxies and interceptors, the framework can execute infrastructural logic before, after or around business method execution without modifying the business components themselves.

AOP externalizes cross-cutting concerns such as transaction management, logging, security validation and monitoring into dedicated infrastructural aspects managed by the container. During runtime execution, proxies intercept method invocations and dynamically apply the required infrastructural behavior around the target operation.

This mechanism allows runtime behavior to remain centralized, reusable and transparently integrated into the execution flow while preserving clean business-oriented application design.

8.4.4 Transaction Management

Transaction Management coordinates consistency and reliability throughout the runtime execution pipeline. During transactional execution, the transaction manager establishes execution boundaries, synchronizes persistence resources and controls commit or rollback behavior depending on the execution outcome.

The transactional infrastructure remains deeply integrated with AOP interception because transactional behavior is commonly applied through runtime proxies surrounding business methods. Once execution begins, the transaction manager coordinates persistence synchronization, resource allocation and transactional consistency across all participating persistence operations.

This model guarantees atomic execution behavior while allowing business components to remain independent from low-level transaction APIs and infrastructural synchronization concerns.

8.4.5 Persistence Integration

Persistence Integration represents the runtime persistence coordination layer responsible for synchronizing domain entities, persistence contexts and database resources during execution.

Repositories provide abstraction over persistence access, while the Entity Manager coordinates entity lifecycle management and persistence synchronization. The Persistence Context maintains a consistent in-memory representation of managed entities throughout the active transaction scope.

During execution, the ORM infrastructure translates object-oriented state transitions into database operations while the transaction manager coordinates synchronization and consistency with the underlying persistent storage system.

Persistence Integration therefore allows enterprise applications to manipulate domain entities while the runtime infrastructure transparently coordinates SQL generation, persistence synchronization and transactional consistency internally.

8.5 Transparency of Execution

One of the defining characteristics of the Runtime Execution Model is execution transparency. Although enterprise applications may involve complex infrastructural coordination internally, business components interact primarily with simple domain-oriented abstractions while the runtime infrastructure manages operational complexity automatically.

Developers typically invoke ordinary methods, manipulate entities and interact with repositories without explicitly controlling transactions, persistence synchronization, proxy execution or infrastructural resource management. The container transparently orchestrates these responsibilities through the runtime execution pipeline.

This transparency is possible because infrastructural concerns are externalized into container-managed services coordinated dynamically during execution. Proxies intercept method invocations, aspects apply runtime behavior, transaction managers synchronize execution boundaries and persistence frameworks coordinate entity state transitions without exposing infrastructural complexity directly to the business layer.

The result is a programming model where application code remains focused on business behavior while the runtime environment manages infrastructural orchestration transparently behind the execution flow.

8.6 Determinism and Consistency

The Runtime Execution Model provides deterministic and consistent execution behavior across enterprise applications by centralizing infrastructural coordination inside the container-managed runtime environment.

Because object lifecycles, dependency wiring, runtime interception, transaction boundaries and persistence synchronization are all controlled by the framework, execution behavior becomes predictable and standardized throughout the application architecture. Operations execute under coordinated infrastructural rules rather than relying on manual resource handling or inconsistent application-level coordination.

Transactional boundaries guarantee atomic execution, persistence contexts maintain synchronized entity state and container-managed execution pipelines ensure that infrastructural behavior executes consistently across all business operations.

This deterministic model significantly improves reliability, scalability and maintainability because enterprise applications operate within a controlled runtime environment capable of coordinating complex infrastructural interactions systematically.

The Runtime Execution Model therefore represents the final integration layer of the container-managed architecture, unifying IoC, Dependency Injection, AOP, Transaction Management and Persistence Integration into a single coordinated execution system responsible for reliable enterprise application behavior.

Objects are created in the heap and over time many of them become unreachable. Instead of requiring manual memory management, the JVM automatically detects these unused objects and frees their memory.

Understanding how GC works helps you write applications that use memory more efficiently and behave more predictably under load, especially in systems where performance and responsiveness matter.

JVM Heap

The heap is divided into generations:

Young Generation

Where new objects are created:

• Eden Space (most objects die here)
• Survivor Spaces (S0 / S1)

Old Generation (Tenured)

Long-lived objects move here.

Metaspace

Stores class metadata (Java 8+ uses native memory, not heap).
Before Java 8, this area was called PermGen (Permanent Generation).

Every GC algorithm balances:
Throughput: How much work the app does
Latency: How long GC pauses are
You cannot maximize both at the same time.

GC Algorithms

Serial GC

Serial GC uses one single thread to perform all garbage collection tasks.
When garbage collection starts, the JVM pauses all application threads (Stop-the-World) and executes the cleanup process sequentially using only one thread.
It is called Serial GC because every garbage collection phase runs one after another in a single GC thread.
Because there is no coordination between multiple GC threads, Serial GC has low overhead and works well on small systems. However, pause times become longer as heap size grows.

How Serial GC Works

Mark

The JVM starts from GC Roots (local variables in stacks, static fields, active threads, JNI references) and follows object references.
Every object that can still be reached is marked as alive. Objects that are not reached are considered garbage.

Sweep

After marking is complete, unreachable objects become reclaimable and their memory can be reused.

Copy (Young Generation)

The Young Generation is the heap area where new objects are created. Most of these objects are temporary and die quickly.
This area is commonly divided into:

• Eden: where new objects are allocated
• Survivor From: survivor space used in the current cycle
• Survivor To: empty survivor space used as destination

When a Minor GC occurs:

1. The JVM checks objects in Eden and Survivor From.
2. Objects that are still alive are copied into Survivor To.
3. Dead objects are ignored and left behind.
4. After copying finishes, Eden and Survivor From are cleared.
5. Survivor spaces switch roles for the next collection.

Instead of deleting dead objects one by one, the JVM copies only the live objects and reuses the previous memory areas.
This is efficient because usually only a small number of young objects survive.

Compact

During Full GC, surviving objects in the Old Generation may be moved together into continuous memory blocks.
This removes empty gaps between objects (fragmentation) and makes future memory allocation easier and faster.

Memory Strategy

• Young Generation: uses copying collection
• Old Generation: uses mark-sweep-compact
• All GC work: handled by one single thread

Minor GC vs Full GC

• Minor GC: processes the Young Generation
• Full GC: processes the entire heap and causes longer pauses

When to Use

• Small applications
• Containers with strict CPU limits
• Single-core or low-resource machines

When to Avoid

• Large heap sizes
• Multi-core servers
• Low-latency systems
• High-traffic backend services

Enable

-XX:+UseSerialGC

Pros

• Simple design
• Low memory overhead

Cons

• Long Stop-the-World pauses
• Poor scalability
• Does not take advantage of multiple CPUs

Serial GC uses one single thread to perform all garbage collection tasks.
When GC starts, the JVM pauses all application threads (Stop-the-World) and runs the collection process sequentially.

Young Generation → Minor GC
The Young Generation is divided into:
Eden
Survivor 0 (S0)
Survivor 1 (S1)
New objects are created in Eden.
When Eden becomes full, a Minor GC starts.
Serial GC uses a Copying Collector.
Process:
The JVM checks objects in Eden.
Live objects are copied to the empty Survivor space.
Dead objects are discarded.
Eden is cleared.
Survivor spaces switch roles (S0 ↔ S1).
Each surviving object increases its age.
Objects that survive enough GC cycles are promoted to the Old Generation.
Example:
Eden → S0
Next GC: Eden + S0 → S1
Next GC: Eden + S1 → S0
After enough survival cycles → Old Generation
This is efficient because most young objects die quickly.

Old Generation → Full GC
The Old Generation stores long-lived objects promoted from Young Generation.
When memory becomes insufficient, Serial GC performs a Full GC using Mark-Sweep-Compact.
Process:
Mark
Reachable objects are identified from GC Roots.
Sweep
Unreachable objects are removed.
Compact
Remaining live objects are moved together into contiguous memory blocks.
This removes fragmentation and creates free continuous space.

Parallel GC

Parallel GC uses multiple threads to perform garbage collection.
When garbage collection starts, the JVM pauses all application threads (Stop-the-World) and distributes the collection work across several CPU cores.
Its main objective is throughput, meaning it tries to maximize the total amount of application work completed over time.
Compared with Serial GC, it completes garbage collection faster on multi-core machines.
For many years, Parallel GC was the default collector for many server workloads.
Parallel GC is optimized for throughput, not for low pause times.

How Parallel GC Works

Young Generation

The Young Generation stores newly created objects, most of which die quickly.
Parallel GC uses a parallel copying collector for this area.
During a Minor GC:

1. Multiple GC threads scan Eden and Survivor spaces.
2. Live objects are copied into an empty Survivor space.
3. Dead objects are discarded.
4. The reclaimed memory becomes available for new allocations.

Because most young objects do not survive long, this phase is usually fast and efficient.

Old Generation

Objects that survive several Young Generation collections are promoted to the Old Generation.
Parallel GC usually uses parallel mark-sweep-compact for this area.

During a Full GC:

1. Live objects are identified.
2. Unreachable objects are reclaimed.
3. Surviving objects may be compacted to remove fragmentation.

This phase is heavier and causes longer pauses.

Core Behavior

• Young Generation: parallel copying collection
• Old Generation: parallel mark-sweep-compact
• Minor GC: frequent and faster
• Full GC: less frequent, slower and processes the entire heap

When to Use

• Multi-core servers
• Batch processing systems

When to Avoid

• Low-latency systems
• Real-time applications
• Systems sensitive to long pauses

Enable

-XX:+UseParallelGC

Pros

• High throughput
• Good CPU utilization
• Faster than Serial GC on multi-core hardware
• Good choice for throughput-focused workloads

Cons

• Stop-the-World pauses still occur
• Full GC can be expensive on large heaps
• Not ideal for latency-sensitive systems

Parallel GC uses multiple GC threads to perform garbage collection work in parallel.
When GC starts, the JVM pauses all application threads (Stop-the-World), but the cleanup work is divided across several CPU cores.

Young Generation → Minor G
Parallel GC uses a Parallel Copying Collector.
Process:
Multiple GC threads scan Eden and the active Survivor space.
Live objects are copied in parallel to the empty Survivor space.
Dead objects are discarded.
Eden is cleared.
Survivor spaces swap roles (S0 ↔ S1).
Surviving objects increase their age.
Objects that survive enough cycles are promoted to Old Generation.
This is similar to Serial GC, but faster because several GC threads work at the same time.

Old Generation → Full GC
When more space is needed, Parallel GC performs a Full GC using Parallel Mark-Sweep-Compact.Process:
Mark
Multiple threads identify reachable objects from GC Roots.
Sweep
Unreachable objects are reclaimed.
Compact
Surviving objects are moved together to eliminate fragmentation.
This creates larger continuous free memory blocks.

CMS GC (Concurrent Mark Sweep)

CMS GC uses multiple threads and performs most garbage collection work concurrently with the application threads.

Its main goal is to reduce long Stop-the-World pauses, making response times more stable.
Unlike Serial GC and Parallel GC, which pause the entire application during most collection phases, CMS performs much of the marking and sweeping while the application continues running.

Because of this, CMS became popular in latency-sensitive server applications, where shorter pauses were more important than maximum throughput.

However, CMS had important limitations:

• It does not compact memory by default, which can cause fragmentation.
• It uses extra CPU while running concurrently.
• Large heaps could still trigger long fallback Full GC pauses.

CMS was deprecated in Java 9 and later removed, because newer collectors like G1 Garbage Collector provided lower pauses with better memory management and simpler operation.

How CMS Works

Initial Mark

The JVM pauses the application for a very short time.
In this phase, it marks Old Generation objects that are reachable from GC Roots, such as:

• local variables in thread stacks
• static variables
• active threads
• JNI references

This is only the starting point, so the pause is short.

Concurrent Mark

The application resumes execution.
While the program continues running, CMS follows references starting from the objects marked in the previous phase.
It identifies all reachable objects in the Old Generation.
This is usually the longest phase, but the application keeps running.

Remark

The JVM pauses the application again for a short time.
During Concurrent Mark, the application may have changed references between objects.
Remark updates the marking information so the JVM knows exactly which objects are still alive.

Concurrent Sweep

The application continues running.
CMS removes unreachable objects from the Old Generation and reclaims that memory.
Dead objects are deleted while the application remains active.

Important Limitation: No Compaction

CMS normally uses Mark + Sweep, but not Compact.
That means live objects are not moved together after cleanup.

Example:

Before Sweep:

[A][dead][B][dead][C]

After Sweep:

[A][free][B][free][C]

Free memory remains separated in small empty spaces.
This is called fragmentation.
Over time, fragmentation can create allocation problems for large objects.

Memory Strategy
Young Generation: Minor GC
Old Generation: CMS
Goal: reduce pause times

Enable

-XX:+UseConcMarkSweepGC

Pros

• Lower pause times than Parallel GC
• Much of the work runs concurrently
• Good for latency-sensitive workloads

Cons

• Deprecated and removed from modern JVMs
• Can suffer from memory fragmentation
• More CPU overhead than Serial / Parallel GC
• May fall back to Full GC in some situations

CMS GC uses multiple threads and performs most garbage collection work concurrently with the application.
Its main goal is to reduce long Stop-the-World pauses.
CMS works mainly on the Old Generation.
The Young Generation is collected with Minor GC.

CMS Collection Stages (Old Generation)
1. Initial Mark
Application pause.
The JVM marks Old Generation objects reachable from GC Roots.
2. Concurrent Mark
The application continues running.
GC threads trace references and identify all reachable objects in the Old Generation.
3. Remark
Application pause.
The JVM updates reference changes that happened while Concurrent Mark was running.
4. Concurrent Sweep
The application continues running.
GC threads remove unreachable objects from the Old Generation and reclaim memory.
5. No Compaction
CMS does not move surviving objects together after sweep.
This can produce memory fragmentation.

G1 GC (Garbage First)

G1 GC is a designed to deliver balance between throughput, pause time and scalability.
It was built for multi-core machines and large heaps, where older collectors often struggled with long pauses.
Because it performs well across many workloads, G1 became the default collector in modern versions of the Java Virtual Machine.

Why It Is Called Garbage First

The name comes from its strategy.
Instead of cleaning memory in one massive operation, G1 identifies the heap areas containing the most reclaimable garbage and prioritizes those first.
This allows the JVM to recover memory while keeping pauses more controlled.

Region-Based Memory Layout

Traditional collectors divide the heap into fixed contiguous spaces such as Young Generation and Old Generation.
G1 uses a different model.
The heap is split into many small, equally sized regions. These regions are managed and the JVM can dynamically assign them as:

• Eden
• Survivor
• Old
• Free space

This design gives G1 much more flexibility than older collectors.

How G1 GC Works

Young Collection

When Eden regions fill up:

• The application pauses briefly.
• Multiple GC threads process those regions.
• Live objects are copied to Survivor or Old regions.
• Empty regions are reclaimed.

This is similar to a Minor GC in traditional generational collectors.

Concurrent Marking

G1 periodically starts a background marking cycle to analyze old regions.
Its purpose is to determine:

• which objects are still alive
• which regions contain the most garbage

Most of this work happens while the application continues running, which helps reduce long stop-the-world pauses.

Mixed Collection

After marking finishes, G1 continues doing Young collections, but it also includes selected Old regions with high garbage content.
Instead of reclaiming the entire Old Generation at once, G1 cleans old memory over multiple cycles.
This is one of the reasons G1 usually avoids long pauses.

Compaction

Because objects are copied between regions during collection, memory is compacted.

That means:

• fewer fragmented gaps
• better memory organization
• easier allocation of large objects

Collection Types

Young GC
Processes Eden and Survivor regions. Short pauses.

Mixed GC
Processes Young regions plus selected Old regions. Moderate pauses.

Full GC
Processes the entire heap. Used as fallback and expensive.

fast cleanup of short-lived objects
gradual cleanup of old memory
predictable pause times
solid throughput performance

When to Use G1

G1 is a strong choice for:

• Large server applications
• Multi-core environments
• Medium to large heaps
• Systems needing balanced latency and throughput

When to Avoid G1

G1 may be less ideal for:

• Very small applications
• Ultra-low-latency systems where Z Garbage Collector or Shenandoah GC can be better choices

Enable G1 GC

-XX:+UseG1GC

Advantages

• Good balance between throughput and pause time
• Predictable pause behavior
• Handles large heaps well
• Reduces fragmentation through compaction

Disadvantages

• Full GC is still expensive if triggered
• Not ideal for extreme low-latency systems

G1 GC balance throughput, pause times and scalability. It was created for multi-core and large heaps, where older collectors often produced long pauses.

Unlike traditional collectors that split memory into fixed Young and Old spaces, G1 divides the heap into many equal-sized regions. These regions are managed independently.

Its name, Garbage First, comes from its strategy of prioritizing the regions with the highest amount of reclaimable memory. By collecting the most valuable regions first, G1 improves memory recovery while keeping pauses more predictable.

G1 combines several mechanisms to achieve this. It performs regular Young collections for short-lived objects, runs concurrent marking in the background to analyze old regions and executes mixed collections that gradually reclaim old memory instead of processing the whole heap at once.

Because objects are copied between regions during collection, memory is also compacted, which reduces fragmentation and helps future allocations.

ZGC (Z Garbage Collector)

ZGC is a garbage collector designed to keep pause times short, even when the application uses large amounts of heap memory.
Traditional collectors perform significant work during Stop-the-World phases. As heap size grows, those pauses become more noticeable because the JVM must process more memory during collection cycles. ZGC was created to move most of that work into concurrent phases that run while the application continues executing.
Its main objective is low latency: reduce long GC interruptions while maintaining efficient memory reclamation.

Core Design of ZGC

ZGC is built on three main principles:

• Region-based heap
• Mostly concurrent collection
• Concurrent relocation of live objects

Instead of treating the heap as one large area, ZGC divides memory into many smaller regions. These regions can be processed independently, which improves scalability and allows reclamation in smaller steps.

Heap Layout

The heap is split into multiple regions.

Each region contain allocated objects or free space. During collection, ZGC select specific regions to inspect, relocate or reclaim without processing the entire heap at once.

This is one reason ZGC behaves well with large heaps.

Main Collection Phases

1. Pause Mark Start

A short Stop-the-World pause.

The JVM pauses application threads to capture GC Roots, such as:

• thread stack references
• CPU register references
• static field references
• JNI references

These roots are the starting points used to discover reachable objects.
Only this initial synchronization is paused, so the phase remains short.

2. Concurrent Mark

The application resumes running.

GC threads traverse references starting from the captured roots and mark all reachable objects as live.

This is usually the largest marking phase, but it happens concurrently with normal application execution.

3. Pause Mark End

Another short Stop-the-World pause.

The JVM finalizes marking and accounts for reference changes that occurred while concurrent marking was running.

This gives the collector a consistent view of which objects are still alive.

4. Concurrent Relocation

ZGC selects regions that contain reclaimable garbage and moves surviving objects to other regions.

This relocation happens while the application continues running.

Older collectors often compact memory during long pauses. ZGC performs object movement concurrently instead.

5. Concurrent Reclaim

After relocation finishes, regions that no longer contain live objects are released.

Those regions become available for future allocations.

Colored Pointers

ZGC uses colored pointers, meaning object references include metadata bits used internally by the JVM.

These bits help track object state during the GC cycle, such as whether an object has been marked or relocated.

This mechanism supports concurrent movement of objects.

Load Barriers

ZGC uses load barriers when reading references.

If the application accesses an object that was moved during relocation, the JVM can detect the old reference, resolve the new location, and continue safely.

This allows relocation without long global pauses.

Fragmentation Control

Because live objects are regularly relocated, free memory is consolidated over time.

This reduces fragmentation and helps future allocations find usable contiguous space.

Generational ZGC

Early ZGC versions were non-generational.

Newer JVM versions introduced Generational ZGC, which separates:

• young objects (usually short-lived)
• old objects (long-lived)

This improves efficiency while preserving the same low-pause model.

When ZGC Is Useful

ZGC is commonly chosen for:

• APIs with latency requirements
• systems sensitive to pause spikes
• applications with very large heaps

When ZGC May Be Unnecessary

ZGC may be excessive for:

• small applications
• tiny heaps

Enable ZGC

-XX:+UseZGC

ZGC keeps pauses short by limiting Stop-the-World work to brief synchronization steps. Marking, relocation and memory reclamation happen mostly while the application continues running. Its region-based design, load barriers and concurrent relocation make it a strong collector for large, latency-sensitive JVM systems.

Shenandoah GC

Shenandoah GC uses multiple threads and performs most garbage collection work concurrently with the application.
Its main objective is to provide low pause times, especially on large heaps.
Like ZGC, Shenandoah was designed to keep pause times low regardless of heap size by moving heavy GC work out of Stop-the-World phases.
Because of this, Shenandoah is a choice for systems that require consistent responsiveness and low latency.
Shenandoah was originally developed by Red Hat and later integrated into OpenJDK.

How Shenandoah GC Works

Region-Based Heap

Shenandoah divides the heap into independent regions.
This allows the JVM to reclaim memory in smaller units instead of processing the whole heap at once.

Concurrent Mark

Shenandoah identifies live objects while the application continues running.
Most of the marking phase happens concurrently, reducing long pauses.

Concurrent Evacuation

Instead of waiting for a long pause to compact memory, Shenandoah moves live objects to new regions while the application is still running.
References are updated using read/write barriers.

Short Pause Phases

Very short Stop-the-World pauses are still required for synchronization and update steps.
These pauses are designed to remain minimal.

Compaction

Because objects are continuously evacuated to new regions, fragmentation is greatly reduced.

Young / Old Generation Behavior

Early Shenandoah versions were non-generational.
Newer versions introduced generational Shenandoah, allowing separate handling of young and old objects for better efficiency.
Its main design goal remains minimizing pause times across the heap.

When to Use

• Large heap applications
• Low-latency backend systems
• Modern OpenJDK environments

When to Avoid

• Very small applications
• Simple workloads where G1 is sufficient
• JVM distributions without Shenandoah support

Enable

-XX:+UseShenandoahGC

Pros

• Very low pause times
• Scales well with large heaps
• Concurrent compaction reduces fragmentation
• Good for latency-sensitive workloads

Cons

• Higher runtime complexity
• May use more CPU overhead than simpler collectors
• Not always available in every JVM distribution

Technical Summary

Garbage collectors differ in how they reclaim unused objects, how memory is organized.

Older collectors use a classic generational heap:

• Young Generation: where new objects are created
• Old Generation: where long-lived objects are promoted

Newer collectors often use a region-based heap, where memory is split into many equal regions managed independently.

Serial GC

Serial GC uses a single GC thread for all collection work.

Young Generation

When Eden fills, a Minor GC runs:

1. Scan objects in Eden and active Survivor space
2. Copy reachable objects to empty Survivor space
3. Discard unreachable objects
4. Swap Survivor spaces
5. Promote aged objects to Old Generation

Old Generation

When Old memory is full, Full GC runs:

1. Mark reachable objects
2. Sweep unreachable objects
3. Compact live objects together to remove gaps

Characteristics

• single-threaded
• all GC phases stop the application

Parallel GC

Parallel GC uses the same collection model as Serial GC, but with multiple GC threads.

Young Generation

Minor GC uses parallel copying:

1. Scan Eden + Survivor spaces in parallel
2. Copy live objects
3. Discard dead objects

Old Generation

Full GC uses parallel:

1. Mark
2. Sweep
3. Compact

Characteristics

• multiple GC threads
• Stop-The-World during GC
• optimized for throughput

CMS (Concurrent Mark Sweep)

CMS reduces pause time in Old Generation.

Young Generation

Uses traditional Minor GC copying collection.

Old Generation

Main stages:

Initial Mark

Short pause. Marks objects reachable from roots.

Concurrent Mark

Application continues running while collector marks reachable objects.

Remark

Short pause. Updates changes that happened during concurrent mark.

Concurrent Sweep

Application continues running while dead objects are reclaimed.

Characteristics

• Old Generation collected mostly concurrently
• memory fragmentation can appear

G1 GC (Garbage First)

G1 uses a region-based heap.

Heap is divided into many equal regions. Regions can act as:

• Eden
• Survivor
• Old
• Free

Main Stages

Young GC

Collects Young regions and copies live objects elsewhere.

Initial Mark

Short pause to start marking.

Concurrent Mark

Marks live objects while application runs.

Remark

Short pause to finalize marking.

Cleanup

Selects regions with high reclaimable garbage.

Mixed GC

Collects Young regions plus selected Old regions.

Characteristics

• region-based design
• compaction through evacuation
• balanced pause time and throughput

ZGC

ZGC is designed for very low pause times.

Uses a region-based heap.

Main Stages

Pause Mark Start

Very short pause to capture roots.

Concurrent Mark

Marks live objects while application runs.

Pause Mark End

Short pause to finalize marking.

Concurrent Relocation

Moves live objects to new regions while application runs.

Concurrent Reclaim

Releases empty regions.

Characteristics

• most work is concurrent
• very short pauses
• uses load barriers and colored pointers

Shenandoah GC

Shenandoah is also focused on low pause times.

Uses a region-based heap.

Main Stages

Initial Mark

Short pause.

Concurrent Mark

Marks live objects while application runs.

Final Mark

Short pause.

Concurrent Evacuation

Moves live objects while application runs.

Update References

Fixes references to moved objects.

Cleanup

Reclaims free regions.

Characteristics

• concurrent compaction
• low pauses
• region-based design

Technical Evolution

Serial GC

Single-threaded full-stop collector.

Parallel GC

Same model with multiple threads.

CMS

Introduced concurrent collection for Old Generation.

G1

Introduced region-based incremental collection.

ZGC / Shenandoah

Move and reclaim memory concurrently with minimal pauses.

• Class Loading: The process of loading, linking, and initializing classes. Linking consists of three phases: verification (ensuring bytecode is safe and follows JVM specifications), preparation (allocating memory for class variables and setting them to default values), and resolution (converting symbolic references to direct references when needed). Initialization executes static initializers and sets static fields to their initial values.
• Memory Management: The JVM manages memory through three main areas: the heap (shared memory pool for object allocation), the stack (per-thread memory for method execution including local variables and call frames), and garbage collection (automatic reclamation of memory occupied by objects that are no longer reachable, preventing memory leaks and managing heap space efficiently).
• Execution Engine: The component responsible for executing Java bytecode. It uses two main approaches: interpretation (executing bytecode instructions one by one, providing portability but slower performance) and Just-In-Time (JIT) compilation (converting frequently executed bytecode to native machine code at runtime for optimal performance). The JVM typically starts with interpretation and switches to JIT compilation for hot methods.
• Thread Management: Creating and scheduling threads
• Security: The JVM implements a security model called “sandboxing” that restricts untrusted code from performing potentially harmful operations. This includes bytecode verification to ensure code safety, security managers that enforce access policies, and class loaders that isolate code from different sources. Access control is managed through permissions and security policies that define what operations (like file access, network connections, or system property modifications) are allowed for different code sources.
• Performance Optimization: The JVM employs Just-In-Time (JIT) compilation to translate frequently executed bytecode into native machine code, significantly improving performance. Adaptive optimization dynamically analyzes runtime behavior to apply optimizations like method inlining, loop unrolling, dead code elimination, and escape analysis. The JVM uses profiling data to decide which methods to compile and at what optimization level, balancing compilation time with execution speed.

The Java Virtual Machine (JVM) is the environment that runs Java bytecode. Its main internal parts are:

Class Loading: Loads classes into memory, verifies bytecode safety, prepares variables, resolves references, and runs static initialization.
Memory Management: Uses the heap for objects, the stack for method calls and local variables, and garbage collection to free unused memory automatically.
Execution Engine: Runs bytecode through interpretation (slower, portable) or JIT compilation (faster, converts hot code into native machine code).
Thread Management: Handles creation, scheduling, and execution of multiple threads.
Security: Protects the system with sandboxing, bytecode verification, class loaders, and permission-based access control.
Performance Optimization: Improves speed using JIT techniques like method inlining, loop optimization, dead code removal, and runtime profiling.

Key Components

• Class Loader Subsystem: Loads classes from various sources
• Runtime Data Areas: Memory areas for program execution
• Execution Engine: Executes bytecode instructions
• Native Interface: Interacts with native libraries
• Garbage Collector: Manages memory automatically

JVM Memory Model

The JVM Memory Model defines how threads interact through memory and what behaviors are allowed in concurrent programs. It specifies:

• Atomicity: Which operations are indivisible
• Visibility: When changes made by one thread are visible to others
• Ordering: The order in which operations appear to execute

Happens-Before Relationship

The memory model is based on the “happens-before” relationship, which defines the order of operations. If operation A happens-before operation B, then the effects of A are visible to B.

Common happens-before relationships:

• Program Order: Within a single thread, operations appear to execute in the order they appear in the program code. This ensures that a thread sees its own operations in the expected sequence.
• Monitor Lock: When a thread unlocks a monitor (exits a synchronized block), this happens-before any subsequent thread locks the same monitor (enters a synchronized block). This ensures proper synchronization between threads using the same lock.
• Volatile Variables: A write to a volatile variable happens-before any subsequent read of the same volatile variable by another thread. This provides visibility guarantees for volatile fields across threads.
• Thread Start/Join: Calling start() on a thread guarantees that everything done before start() is visible to the new thread when it begins execution. Likewise, when join() returns successfully, all actions performed by that thread are guaranteed to be visible to the thread that called join(). This provides safe synchronization for the thread lifecycle.

Code Examples

Volatile variables for visibility

public class SharedState {
    private volatile boolean ready = false;
    private int value;
    
    public void write() {
        value = 42;      // Write value
        ready = true;    // Volatile write - establishes happens-before
    }
    
    public int read() {
        while (!ready) { // Volatile read
            // Spin wait
        }
        return value;    // Guaranteed to see 42
    }
}

Synchronized blocks for atomicity

public class Counter {
    private int count = 0;
    
    public synchronized void increment() {
        count++;  // Atomic operation
    }
    
    public synchronized int getCount() {
        return count;  // Atomic read
    }
}

The JVM Memory Model defines how threads share data in concurrent programs.

Atomicity: operations that happen completely or not at all.
Visibility: when one thread can see changes made by another.
Ordering: the sequence in which operations appear to happen.

It uses the happens-before rule: if action A happens-before action B, then B can see the effects of A.

Program Order: instructions run in order inside one thread.
Monitor Lock: releasing a synchronized lock is visible to the next thread that acquires it.
Volatile: writing to a volatile variable is visible to later reads.
Start/Join: start() and join() ensure safe synchronization between threads.

Thread Stack

Each Java thread has its own private stack, used during method execution. It stores:

• Method frames: data for each active method call, including local variables and temporary values used by the method.
• Return addresses: the point where execution continues after a method finishes.
• Intermediate results: values produced during calculations before the final result is obtained.

The stack works with a push/pop mechanism: when a method is called, a new frame is added to the stack; when the method ends, that frame is removed. This helps the JVM manage method calls while keeping each thread’s execution separate.

Stack Frame Structure

Each stack frame contains:

• Local Variable Array: Method parameters and local variables
• Operand Stack: Temporary memory area used by the JVM to perform calculations and store intermediate results during method execution.
• Frame Data: Additional method execution information, such as references to the constant pool and data used for exception handling.

Stack Size Configuration

// JVM options for stack size
// -Xss256k          // 256KB per thread
// -Xss1m            // 1MB per thread

Common Stack Issues

• StackOverflowError: Occurs when a thread stack exceeds its maximum size, usually caused by deep or infinite recursion. Each method call adds a new frame to the stack, and if calls continue without returning, the stack eventually runs out of space.
• OutOfMemoryError: Happens when the JVM cannot create new stack frames or allocate memory for additional thread stacks. This may occur when the system has insufficient memory available or when too many threads are created.

Code Examples

Recursive method and stack usage

public class Factorial {
    public static long factorial(int n) {
        if (n <= 1) {
            return 1;
        }
        return n * factorial(n - 1);  // Each call adds frame to stack
    }
    
    public static void main(String[] args) {
        // Deep recursion may cause StackOverflowError
        try {
            System.out.println(factorial(10000));
        } catch (StackOverflowError e) {
            System.out.println("Stack overflow occurred");
        }
    }
}

Each stack frame stores the data needed for a method call:

Local Variable Array: parameters and local variables.
Operand Stack: temporary area for calculations and intermediate results.
Frame Data: extra information like constant pool references and exception handling data.

The stack size can be configured with JVM options such as -Xss256k or -Xss1m (default depends on the JVM).

Common problems:
StackOverflowError: stack becomes full, usually due to deep or infinite recursion.
OutOfMemoryError: JVM cannot allocate more stack memory.

Heap

The heap is the runtime data area where objects are allocated. It’s shared among all threads and managed by the garbage collector. Key characteristics:

• Dynamic Allocation: Objects are created at runtime using the new keyword and allocated on the heap. Memory is freed when objects are no longer referenced.
• Shared Memory: All threads in the JVM process access the same heap, allowing threads to share objects and data. This requires synchronization mechanisms to prevent data races and ensure thread safety.
• Garbage Collected: The JVM reclaims memory occupied by unreachable objects through garbage collection.
• Generational: The heap is divided into generations (Young, Old, and Metaspace) based on object lifetime patterns. Most objects die young, so frequent collection of young generation is efficient. Objects that survive multiple GC cycles are moved to older generations for less frequent collection, optimizing collection pause times.

Generational Levels:

• Young Generation (also called Nursery): Where newly created objects are allocated. Contains Eden Space (initial allocation) and two Survivor Spaces. Collected frequently with minor GC because most objects become garbage quickly.
• Old Generation (also called Tenured): Contains long-lived objects that survived multiple minor GC cycles. Collected less frequently with major GC because most objects here are still alive.
• Permanent Generation (Java 7 and earlier) or Metaspace (Java 8+): Stores class metadata, method data, code cache, and interned strings. Collected during full GC. In Java 7 and earlier, PermGen was part of the heap with a fixed size, often causing OutOfMemoryError when too many classes were loaded. In Java 8+, Metaspace was introduced to address this limitation. Metaspace grows dynamically from native memory (off-heap system memory managed by the operating system) rather than from the JVM heap. This means Metaspace can grow as needed up to the system’s available memory, eliminating fixed-size limitations and allowing applications to load more classes without heap space concerns.

The heap size is configured with JVM options:

• -Xms: Initial heap size
• -Xmx: Maximum heap size

Heap Structure

• Young Generation: Newly created objects allocated in this generation. Contains:
• Eden Space: Where all new objects are initially created. Most objects die here within one garbage collection cycle.
• Survivor Space (S0 and S1): Objects that survive garbage collection are moved here. Default ratio is 8:1 (Eden:Survivor).
• Old Generation: Contains long-lived objects that have survived multiple minor garbage collections. Objects move here when they reach a promotion age threshold (default 15 for parallel GC).
• Perm/Metaspace: Stores class structures and metadata that describe loaded classes and methods. Java 8+ uses Metaspace which resides in native memory instead of heap.

Code Examples

Object allocation patterns

public class ObjectAllocation {
    public static void main(String[] args) {
        // Allocate objects in young generation
        List<String> list = new ArrayList<>();
        for (int i = 0; i < 100000; i++) {
            list.add("Object " + i);
        }
        
        // Objects become eligible for GC when method exits
        // list goes out of scope here
        System.gc();  // Suggest garbage collection
    }
}

Heap Areas

The JVM heap is divided into several areas for efficient memory management:

• Young Generation: Where new objects are allocated
• Eden Space: Initial allocation area
• Survivor Spaces (S0, S1): Objects that survive minor GC
• Old Generation (Tenured): Long-lived objects that survive multiple GC cycles
• Permanent Generation/Metaspace: Class metadata, method data, interned strings
• Replaced by Metaspace in Java 8+

Young Generation

• Objects start in Eden space
• Minor GC moves survivors to survivor spaces
• After multiple survivals, objects move to old generation

Old Generation

• Contains objects that have survived many GC cycles
• Collected during major GC (full GC)
• Usually larger than young generation

Metaspace (Java 8+)

• Stores class metadata
• Grows dynamically (no fixed size limit)
• Can cause OutOfMemoryError if unlimited

Code Examples

Configuring heap areas

// JVM options for heap configuration
// -Xms512m -Xmx2g           // Heap size: 512MB initial, 2GB max
// -Xmn256m                  // Young generation: 256MB
// -XX:NewRatio=2            // Old:Young ratio = 2:1
// -XX:SurvivorRatio=8       // Eden:Survivor ratio = 8:1
// -XX:MaxMetaspaceSize=256m // Metaspace limit

JVM Heap Memory
The JVM heap is divided into areas for efficient memory management:
Young Generation: where new objects are created.
Eden Space: initial area where most new objects are allocated. Many objects die here quickly.
Survivor Spaces (S0, S1): objects that survive minor garbage collection are moved here.
Old Generation (Tenured): stores long-lived objects that survived several garbage collection cycles.
Metaspace (Java 8+): stores class metadata and method information in native memory (replaced PermGen). It grows dynamically but can cause OutOfMemoryError if unrestricted.
Garbage Collection Flow
New objects start in Eden.
Surviving objects move to Survivor spaces.
After multiple survivals, they are promoted to Old Generation.
Common JVM Options
-Xms / -Xmx → initial and maximum heap size
-Xmn → young generation size
-XX:SurvivorRatio → Eden/Survivor ratio
-XX:MaxMetaspaceSize → Metaspace limit

The Java Virtual Machine (JVM) is the core runtime environment that makes Java programs portable, secure, and efficient. It executes Java bytecode independently of the operating system, allowing the same program to run on multiple platforms.

The main internal areas of the JVM were analyzed:

• Class Loading, responsible for loading, linking, and initializing classes.
• Memory Management, using the heap, stack, and garbage collection.
• Execution Engine, which runs bytecode through interpretation and JIT compilation.
• Thread Management, enabling concurrent execution.
• Security, through sandboxing, bytecode verification, and access control.
• Performance Optimization, using runtime profiling and adaptive compilation.

The JVM Memory Model was also covered, explaining how threads interact safely through concepts such as atomicity, visibility, ordering, and the happens-before relationship.

In addition, the two most important runtime memory areas were studied:

• Stack, used for method calls, local variables, and thread execution flow.
• Heap, used for object allocation and divided into Young Generation, Old Generation, and Metaspace.

Understanding JVM internals is essential for Java developers because it helps improve:

• Application performance
• Memory usage
• Multithreading correctness
• Error diagnosis
• Efficient code design

The JVM is much more than a program runner: it is a complete execution platform that combines memory management, concurrency control, security, and optimization to make Java reliable and powerful.

Un proceso tiene su propio espacio de memoria independiente, lo que lo hace más aislado y seguro, pero también más pesado en términos de recursos y comunicación. En cambio, los hilos corren dentro de un proceso, comparten la misma memoria, y son más ligeros, pero necesitan sincronización para evitar conflictos
Los pipes y los sockets se usan para la comunicación entre procesos, mientras que la memoria compartida permite que varios procesos accedan a la misma zona de memoria.
Un pipe es un mecanismo de comunicación entre procesos (generalmente en la misma máquina), permitiendo que intercambien datos de forma sencilla a través del sistema operativo. En cambio, un socket se utiliza para la comunicación entre procesos que pueden estar en diferentes máquinas a través de una red. Así que, los pipes suelen usarse para comunicación local entre procesos, mientras que los sockets se usan para comunicación en red.
Los hilos, o threads, corren dentro de un mismo proceso y comparten la misma zona de memoria, lo que los hace más ligeros y eficientes en términos de recursos, porque no tienen que duplicar el espacio de memoria como los procesos. Sin embargo, al compartir memoria, necesitan sincronización para evitar que se produzcan conflictos o datos inconsistentes. Así que, en resumen, son más rápidos y consumen menos recursos, pero requieren un poco más de cuidado con la sincronización.

Los recursos, como el tiempo de CPU, la memoria, los manejadores de archivos, los bloqueos y las conexiones de red, son aspectos clave en la gestión de hilos. Los hilos suelen competir por el tiempo de CPU y, al compartir datos, hay que tener cuidado con la sincronización.

El ciclo de vida de un hilo en Java: desde el estado new hasta terminated

Un hilo comienza en el estado “new” cuando se crea. Luego, al llamar al método start(), pasa al estado “runnable”, que significa que está listo para ejecutarse. En este estado, el hilo puede estar ejecutándose o listo para ejecutarse, esperando CPU. En Java no existe un estado separado llamado “running”, todo eso es “runnable”, esperando que el scheduler le asigne tiempo de CPU.

Si intenta acceder a un recurso sincronizado que está ocupado, puede pasar al estado “blocked”. También puede entrar en estados de espera como “waiting” o “timed waiting” si necesita que ocurra algún evento o esperar cierto tiempo.

Finalmente, cuando termina su ejecución o ocurre un error, pasa al estado “terminated”.

Creación y ejecución de hilos con expresiones lambda

class Example {
  public static void main(String[] args) throws Exception {
    Thread t = new Thread(() -> {
      // work
      for (int i = 0; i < 3; i++) {}
    });
    t.start();
    t.join(); // wait for completion
  }
}

En el ejemplo, creamos un nuevo hilo usando una expresión lambda y en su interior ejecutamos un bucle. Luego, iniciamos el hilo con start() y, en el método main, usamos join() para esperar a que termine antes de continuar. Así aseguramos que el hilo finalice antes de que el programa siga.

Daemon threads

class DaemonDemo {
  public static void main(String[] args) {
    Thread t = new Thread(() -> { while (true) {} });
    t.setDaemon(true);
    t.start();
  }
}

Un hilo demonio, o daemon thread, es un tipo de hilo que no mantiene viva la máquina virtual de Java (JVM) por sí solo. Es decir, si todos los hilos que quedan son demonios, la JVM se apaga. Se usan para tareas en segundo plano, como tareas de limpieza, temporizadores, o procesos que no necesitan finalizar antes de que el programa termine. Eso sí, hay que tener cuidado porque no se garantiza que se ejecuten hasta el final, así que son ideales para tareas que no son críticas.

Un temporizador es básicamente una tarea que se ejecuta después de un cierto intervalo de tiempo, o de forma repetitiva. Por ejemplo, si quieres que se ejecute una acción cada cierto tiempo, como limpiar un caché de manera periódica, usarías un temporizador. Los hilos demonio son perfectos para este tipo de tareas, ya que no interfieren con el cierre de la aplicación.

Thread pools (ExecutorService)

class PoolDemo {
  public static void main(String[] args) throws Exception {
    ExecutorService pool = Executors.newFixedThreadPool(4);
    Future<Integer> f = pool.submit(() -> 40 + 2);

    int answer = f.get(); // blocks
    pool.shutdown();      // stop accepting new tasks
  }
}

El ExecutorService es una interfaz que nos permite gestionar un grupo de hilos de forma más eficiente. En lugar de crear un hilo por tarea, usamos un pool de hilos que se reutilizan. La idea es justamente evitar el costo de crear un hilo nuevo para cada tarea, lo cual puede ser costoso. En su lugar, se usa un pool, que es un conjunto de hilos que se mantienen vivos y se reutilizan.

Concurrent collections (when many threads access collections)

Las colecciones concurrentes son útiles cuando trabajamos con múltiples hilos, porque nos permiten evitar los problemas de concurrencia, como las condiciones de carrera. Hay clases como ConcurrentHashMap, CopyOnWriteArrayList y otras que están diseñadas para ser seguras en entornos con múltiples hilos.

class ConcurrentMapDemo {
  static final ConcurrentHashMap<String, Integer> hits = new ConcurrentHashMap<>();

  static void record(String key) {
    hits.merge(key, 1, Integer::sum); // atomic update
  }
}

El primer parámetro es la clave que queremos actualizar o agregar en el mapa. El segundo parámetro es el valor que queremos sumar o usar si la clave no existe. Y el tercer parámetro es una función que define cómo combinar el valor actual con el nuevo valor. En este caso, la función que se pasa simplemente suma uno al valor actual, o lo inicializa con uno si no existe. De esta manera, cada vez que se llame a este método, el valor asociado a esa clave se incrementa en uno de forma segura y atómica.

Synchronization & locks

La sincronización se asegura de que varios hilos no accedan a los mismos recursos al mismo tiempo, evitando condiciones de carrera. Cuando hablamos de “mutual exclusion”, nos referimos a que solo un hilo puede acceder a un recurso compartido a la vez. La “visibility” asegura que los cambios que hace un hilo sean visibles para los demás. El “monitor lock” es el mecanismo que se utiliza con las palabras clave synchronized para entrar y salir de una sección crítica. El término “happens-before” se refiere a un principio de consistencia que garantiza que las acciones de un hilo se vean antes de las de otro.

class Counter {
  private int value;
  public synchronized void inc() { value++; }
  public synchronized int get() { return value; }
}

En este ejemplo, al usar el modificador synchronized en los métodos inc y get, lo que logras es que solo un hilo pueda acceder a esos métodos a la vez, evitando que dos hilos intenten modificar o leer el valor al mismo tiempo y así se evita la condición de carrera. La palabra clave volatile no es necesaria en este caso, porque el synchronized garantiza la visibilidad y la exclusión mutua. De esta forma, el valor de value siempre estará actualizado y consistente.

wait/notify (intrinsic condition waiting)

class OneSlotBuffer {
  private Integer slot = null;

  public synchronized void put(int x) throws InterruptedException {
    while (slot != null) wait();
    slot = x;
    notifyAll();
  }

  public synchronized int take() throws InterruptedException {
    while (slot == null) wait();
    int x = slot;
    slot = null;
    notifyAll();
    return x;
  }
}

La idea principal es que, cuando un hilo necesita esperar a que se cumpla cierta condición, utiliza el método wait dentro de un bloque sincronizado, y el hilo que cambia esa condición llama a notify() o notifyAll() para despertar a los hilos que estaba esperando. Es importante que el wait se use siempre dentro de un bucle, porque la condición podría cambiar por otras razones, y así se asegura que, cuando el hilo despierte, realmente se cumpla la condición. El concepto de “spurious wakeup” se refiere a que, a veces, un hilo puede despertar sin que realmente se haya cumplido la condición, por eso siempre se usa el bucle para verificarlo.

ReentrantLock (explicit lock)

class LockCounter {
  private final ReentrantLock lock = new ReentrantLock();
  private int value;

  void inc() {
    lock.lock();
    try { value++; }
    finally { lock.unlock(); }
  }
}

Los ReentrantLock son una alternativa a los bloques sincronizados y ofrecen características más avanzadas. Son reentrantes, lo que significa que el mismo hilo puede adquirir el lock varias veces sin quedar bloqueado. Además, permiten usar un tryLock, que intenta adquirir el lock sin bloquear el hilo. También tienen la opción de fairness, que garantiza un acceso justo a los hilos, y permiten condiciones múltiples, es decir, que puedas tener diferentes condiciones de espera.
Tener condiciones múltiples significa que, dentro del mismo lock, puedes crear distintos objetos de condición que permiten que los hilos esperen por diferentes condiciones o eventos. Por ejemplo, tienes varios hilos esperando a que se libere un recurso específico. Con condiciones múltiples, puedes hacer que cada hilo espere a una condición distinta y así no se despiertan todos a la vez, sino solo cuando la condición que les corresponde se cumple.

Volatile

class StopFlag {
  private volatile boolean stop;
  void requestStop() { stop = true; }
  void runLoop() { while (!stop) { /* spin */ } }
}

La palabra clave volatile se utiliza para garantizar la visibilidad de las variables entre hilos. Es decir, cuando un hilo modifica una variable marcada como volatile, el cambio es inmediatamente visible para otros hilos. Sin embargo, volatile no garantiza la atomicidad de operaciones compuestas, como el incremento, que sigue siendo no atómico. En el ejemplo, la variable stop se marca como volatile para que, cuando un hilo cambie su valor a true, el otro hilo que está en el bucle while lo vea de inmediato y pueda salir del bucle. Pero las operaciones compuestas, como count++, no se vuelven atómicas con volatile.

Atomic variables

AtomicInteger, AtomicLong, etc. provide lock-free atomic operations.

class AtomicDemo {
  private final AtomicInteger count = new AtomicInteger(0);

  void inc() { count.incrementAndGet(); }
  int get() { return count.get(); }
}

Las variables atómicas, como AtomicInteger, son muy útiles porque permiten operaciones atómicas sin necesidad de bloques de sincronización. Esto significa que el incremento y la obtención del valor se hacen de forma segura, incluso en entornos con múltiples hilos. En el ejemplo, el método inc incrementa el valor de count y lo devuelve en una sola operación atómica, lo que evita problemas de concurrencia. Y el método get simplemente devuelve el valor actual de manera segura.

CountDownLatch

class LatchDemo {
  public static void main(String[] args) throws Exception {
    CountDownLatch latch = new CountDownLatch(2);

    new Thread(() -> { latch.countDown(); }).start();
    new Thread(() -> { latch.countDown(); }).start();

    latch.await(); // waits for 2 countDown calls
  }
}

El CountDownLatch es una herramienta para sincronizar hilos, porque permite que uno o varios hilos esperen hasta que se cumpla una cierta cantidad de eventos. En el ejemplo, el CountDownLatch se inicializa con un conteo de 2, lo que significa que el hilo principal esperará hasta que dos eventos se hayan completado. Los hilos que inician con el latch.countDown() van reduciendo ese conteo, y el hilo principal, al llamar a latch.await(), se queda esperando hasta que el conteo llegue a cero. De esta forma, se asegura que el hilo principal no siga adelante hasta que los dos hilos secundarios hayan terminado.

Interruption (how to stop threads correctly)

class InterruptDemo {
  public static void main(String[] args) throws Exception {
    Thread t = new Thread(() -> {
      try {
        while (!Thread.currentThread().isInterrupted()) {
          Thread.sleep(50);
        }
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt(); // restore
      }
    });
    t.start();
    t.interrupt();
    t.join();
  }
}

La interrupción de hilos es una forma de indicar a un hilo que debería detener su ejecución, pero no es un stop forzoso. Es decir, cuando se interrumpe un hilo, este debe revisar periódicamente si ha sido interrumpido y decidir cómo actuar.

Si el hilo está bloqueado en una operación como sleep() o wait(), al ser interrumpido lanzará una excepción InterruptedException. Esta excepción limpia el flag de interrupción, por lo que se pierde esa señal.

La buena práctica es que, cuando se captura la excepción, se restablezca el flag de interrupción si no se va a terminar, para que el hilo pueda salir de su estado de bloqueo de forma limpia.

Process: separate memory space; heavier; communication via OS (pipes/sockets/shared memory).
Thread: runs inside a process; shares heap with other threads; cheaper; needs synchronization.
Resources: CPU time, memory, file handles, locks, network connections. Threads mostly compete for CPU + shared data.

Thread lifecycle

NEW: created, not started.
RUNNABLE: eligible to run (may be running or waiting for CPU).
BLOCKED: waiting to enter a synchronized block/method (monitor lock).
WAITING / TIMED_WAITING: waiting (wait(), join(), park(), sleep() with time).
TERMINATED: finished run() (or crashed).

Creating and running threads

class Example {
  public static void main(String[] args) throws Exception {
    Thread t = new Thread(() -> {
      // work
      for (int i = 0; i < 3; i++) {}
    });
    t.start();
    t.join(); // wait for completion
  }
}

Daemon threads

A daemon thread does not keep the JVM alive; when only daemons remain, the JVM can exit.
Use for background helpers (timers/cleanup). Avoid for tasks that must finish (no guarantees at shutdown).

class DaemonDemo {
  public static void main(String[] args) {
    Thread t = new Thread(() -> { while (true) {} });
    t.setDaemon(true);
    t.start();
  }
}

Thread pools (ExecutorService)

Avoid “one thread per task”. Use pools for bounded concurrency, reuse, and queueing.

class PoolDemo {
  public static void main(String[] args) throws Exception {
    ExecutorService pool = Executors.newFixedThreadPool(4);
    Future<Integer> f = pool.submit(() -> 40 + 2);

    int answer = f.get(); // blocks
    pool.shutdown();      // stop accepting new tasks
  }
}

Concurrent collections (when many threads access collections)

Use ConcurrentHashMap, CopyOnWriteArrayList, ConcurrentLinkedQueue, BlockingQueue, etc.
They provide thread-safe operations with better scalability than synchronizing a whole HashMap.

class ConcurrentMapDemo {
  static final ConcurrentHashMap<String, Integer> hits = new ConcurrentHashMap<>();

  static void record(String key) {
    hits.merge(key, 1, Integer::sum); // atomic update
  }
}

Synchronization & locks

synchronized (monitor lock)
Ensures mutual exclusion and visibility (enter/exit creates happens-before edges).

class Counter {
  private int value;
  public synchronized void inc() { value++; }
  public synchronized int get() { return value; }
}

wait/notify (intrinsic condition waiting)

Must be used inside synchronized on the same object.
Always wait in a loop (spurious wakeups).

class OneSlotBuffer {
  private Integer slot = null;

  public synchronized void put(int x) throws InterruptedException {
    while (slot != null) wait();
    slot = x;
    notifyAll();
  }

  public synchronized int take() throws InterruptedException {
    while (slot == null) wait();
    int x = slot;
    slot = null;
    notifyAll();
    return x;
  }
}

ReentrantLock (explicit lock)

More features: tryLock, fairness option, multiple conditions.

class LockCounter {
  private final ReentrantLock lock = new ReentrantLock();
  private int value;

  void inc() {
    lock.lock();
    try { value++; }
    finally { lock.unlock(); }
  }
}

Volatile

volatile gives visibility (reads see the latest write) and orders operations.
It does not make compound actions atomic (e.g., count++ is still not atomic)

class StopFlag {
  private volatile boolean stop;
  void requestStop() { stop = true; }
  void runLoop() { while (!stop) { /* spin */ } }
}

Atomic variables

AtomicInteger, AtomicLong, etc. provide lock-free atomic operations.

class AtomicDemo {
  private final AtomicInteger count = new AtomicInteger(0);

  void inc() { count.incrementAndGet(); }
  int get() { return count.get(); }
}

CountDownLatch

One-time gate: wait until N events happen.

class LatchDemo {
  public static void main(String[] args) throws Exception {
    CountDownLatch latch = new CountDownLatch(2);

    new Thread(() -> { latch.countDown(); }).start();
    new Thread(() -> { latch.countDown(); }).start();

    latch.await(); // waits for 2 countDown calls
  }
}

Interruption (how to stop threads correctly)

interrupt() is a request, not a force-stop.
If a thread is blocked in sleep/wait/join, it throws InterruptedException.
Good practice: on catch, restore the interrupt flag or exit.

class InterruptDemo {
  public static void main(String[] args) throws Exception {
    Thread t = new Thread(() -> {
      try {
        while (!Thread.currentThread().isInterrupted()) {
          Thread.sleep(50);
        }
      } catch (InterruptedException e) {
        Thread.currentThread().interrupt(); // restore
      }
    });
    t.start();
    t.interrupt();
    t.join();
  }
}

Thread-related exceptions

IllegalThreadStateException: calling start() twice.
InterruptedException: blocking method interrupted (wait/sleep/join/await).
RejectedExecutionException: task submitted to a shutdown executor.
ExecutionException: a Future task threw an exception (wrapped).

Concurrency patterns

Producer–Consumer: use BlockingQueue to connect stages.
Immutable objects: share freely without locks.
Thread confinement: keep state on one thread (no sharing).
Guarded suspension: wait until a condition becomes true (while (!cond) wait()).
Fork/Join: split work; use ForkJoinPool for CPU-bound parallelism.

class ProducerConsumer {
  private final BlockingQueue<Integer> q = new ArrayBlockingQueue<>(10);

  void start() {
    new Thread(() -> { // producer
      try { for (int i = 0; i < 100; i++) q.put(i); }
      catch (InterruptedException e) { Thread.currentThread().interrupt(); }
    }).start();

    new Thread(() -> { // consumer
      try { while (true) q.take(); }
      catch (InterruptedException e) { Thread.currentThread().interrupt(); }
    }).start();
  }
}

Overall summary

Java concurrency deals with multiple threads executing within a process and competing for shared resources such as CPU time and memory. Threads are lightweight compared to processes, but introduce complexity due to shared state and the need for coordination.

A thread goes through a defined lifecycle (NEW, RUNNABLE, BLOCKED, WAITING/TIMED_WAITING, TERMINATED) and can be created and managed directly or through higher-level abstractions like thread pools (ExecutorService), which handle execution, reuse, and task scheduling more efficiently.

Concurrency requires controlling access to shared data. This can be achieved using:

synchronized blocks and intrinsic locks for mutual exclusion and visibility
explicit locks (ReentrantLock) for more advanced control
volatile variables for visibility guarantees
atomic variables for lock-free operations

Thread communication and coordination are handled through:

wait/notify mechanisms inside synchronized contexts
higher-level utilities such as CountDownLatch and BlockingQueue
thread interruption, which provides a cooperative way to stop execution

Java also provides concurrent collections (e.g., ConcurrentHashMap) that allow safe and scalable access to shared data without full synchronization.

Common issues in concurrent programs include race conditions, improper synchronization, and incorrect handling of thread lifecycle or interruption. Exceptions such as InterruptedException, IllegalThreadStateException, and ExecutionException are part of normal concurrency control flow.

Concurrency patterns like producer–consumer, thread confinement, immutability, and task parallelism (Fork/Join) help structure solutions and reduce complexity.

In all cases, the objective is to ensure correct execution, safe data sharing, and proper coordination between threads while making efficient use of system resources.

Pasos clave:
Identificar las entidades del dominio: Qué conceptos son importantes (por ejemplo, Order, Customer, Stock ).
Definir las relaciones entre las entidades: Cómo interactúan entre sí.
Establecer las reglas del negocio: Qué comportamientos y restricciones existen (por ejemplo, invariantes que siempre deben cumplirse).

Conceptos clave:
Lenguaje ubicuo: Términos compartidos con todos los stakeholders.
Entidades y objetos de valor: Definición clara de cada elemento del dominio.
Servicios del dominio y agregados: Cómo se agrupan y se gestionan las reglas.
Reglas de negocio: Condiciones invariantes que siempre deben cumplirse.
Casos de uso: Operaciones del sistema (por ejemplo pagar, cancelar ).

Object-Oriented Conceptos

Abstracción: La idea es enfocarse en lo que realmente importa. Se modelan el comportamiento.
Encapsulamiento: Se protege el estado interno de los objetos y solo se permiten cambios a través de métodos que respetan las reglas definidas.
Herencia: Permite reutilizar código mediante la especialización, pero con cuidado, ya que puede generar acoplamiento. En general, es mejor preferir la composición.
Polimorfismo: Se programa contra interfaces, lo que permite cambiar las implementaciones sin afectar al código que las utiliza.
Composición: Consiste en construir objetos a partir de otros, lo cual suele ser más flexible y permite una mayor reutilización.

Design Principles

Single Responsibility Principle (SRP): Una clase debe tener una única razón para cambiar. Esto significa que cada clase debe tener una responsabilidad bien definida y no mezclarse con otras responsabilidades.
Open/Closed Principle (OCP): Las entidades de software (como clases o módulos) deben estar abiertas para su extensión, pero cerradas para su modificación. Esto permite añadir nuevas funcionalidades sin alterar el código existente.
Dependency Inversion Principle (DIP): Debemos depender de abstracciones y no de implementaciones concretas. Esto facilita el cambio de implementaciones sin afectar el resto del sistema.

Clases y Objetos:

Clase: Define la estructura y el comportamiento. Es como una plantilla.
Objeto: Es una instancia de una clase, es decir, una entidad concreta con valores específicos.
Superclase y Subclase: La subclase hereda el estado y el comportamiento de la superclase.
Relación “es un”: La subclase es un tipo especializado de la superclase.
Sobrescritura de métodos: Una subclase puede sobrescribir un método de la superclase para modificar su comportamiento.
Evitar jerarquías profundas: Es recomendable mantener las jerarquías simples y claras para que el código sea más fácil de mantener.

Clases Abstractas y Finales

Clases Abstractas: No se pueden instanciar: Una clase abstracta sirve como base para otras clases, pero no se puede crear un objeto directamente de ella.
Puede tener estado: Las clases abstractas pueden definir atributos y métodos concretos.
Métodos abstractos: Pueden tener métodos sin implementación que las subclases deben implementar.

Clases Finales: No se pueden extender: Una clase final no puede ser heredada.
Métodos finales: Un método final no puede ser sobrescrito por las subclases.
Variables finales: Una variable final no puede ser reasignada después de su inicialización.

Nota:
Aunque un objeto referenciado por una variable final no pueda ser reasignado, sus atributos internos pueden seguir siendo mutables.

Interfaces

Una interfaz define un contrato que las clases implementan, especificando qué métodos deben estar presentes.
Métodos por defecto: Desde Java 8, las interfaces pueden tener métodos con implementación, lo que facilita la evolución de las interfaces sin romper las clases que las implementan.

Casting en Java: Upcast y Downcast

Upcast: Es cuando asignamos una instancia de una subclase a una variable de su superclase.
Es seguro implícitamente: No se necesita un cast explícito porque la subclase “es un tipo” de la superclase.
Ejemplo: Si tenemos una clase A y una clase B que extiende de A, podemos asignar un objeto de B a una variable de tipo A sin problema.

Downcast: Es cuando asignamos una variable de una superclase a una subclase.
No es seguro implícitamente: Puede fallar en tiempo de ejecución si el objeto no es realmente de ese tipo.
Uso de instaceof: Antes de realizar un downcast, es recomendable usar el operador instaceof para asegurarnos de que el objeto es del tipo esperado.
Pattern Matching (desde Java 16): Facilita el proceso de verificación y casting en una sola línea.

Precaución con el downcast: Si el downcast es incorrecto, se lanzará una excepción ClassCastException en tiempo de ejecución.

Clases Internas en Java

Inner Class (Clase Interna No Estática):
Referencia a la instancia externa: Las clases internas no estáticas tienen acceso directo a los miembros de la clase externa, incluso a sus miembros privados.
Necesita una instancia de la clase externa: Para crear una instancia de una clase interna no estática, se necesita primero una instancia de la clase externa.

Static Nested Class (Clase Anidada Estática):
No tiene acceso a la instancia externa: A diferencia de las clases internas no estáticas, las clases anidadas estáticas no tienen acceso implícito a los miembros de la clase externa.
Comportamiento similar a una clase normal: Se comporta como una clase independiente, aunque sigue estando dentro del contexto de la clase externa.

Anonymous Class (Clase Anónima):
Se usa para crear una clase en el momento, generalmente para implementar una interfaz o una clase abstracta.
Sin nombre: No tiene nombre y se declara en el lugar donde se necesita.
Uso común: Antes de las lambdas, se utilizaban mucho para manejar eventos o crear implementaciones rápidas.

Mapeo del Dominio: Identificación de Entidades y Casos de Uso

Primero, extraemos los sustantivos y los verbos de las declaraciones. Los sustantivos suelen ser candidatos a convertirse en entidades, como por ejemplo: la orden, el cliente, el producto. Los verbos, en cambio, son las acciones o casos de uso, como pagar una orden, cancelar, o reservar stock.
Después, clasificamos estos elementos: las entidades son aquellas que tienen una identidad y un ciclo de vida, como la orden. Los objetos de valor son inmutables y se comparan por valor, como el dinero. Y los servicios de dominio contienen lógica que no pertenece a una sola entidad, como el servicio de precios.
Con este método, logramos una estructura muy clara y organizada del dominio

Las invariantes son reglas de negocio que siempre deben mantenerse verdaderas. Son como las condiciones que garantizan la consistencia y la validez de los datos.
Por ejemplo, la regla de que una orden pagada no puede ser cancelada es una invariante porque, una vez que se pagó, esa condición no debe cambiar. De igual manera, que la cantidad de un producto sea mayor que cero es una invariante.
En resumen, las invariantes son esas reglas que aseguran que el sistema siempre esté en un estado válido.

Agregados en el Diseño de Dominio

Un agregado es un grupo de objetos que se tratan como una unidad única en la persistencia y en las reglas de negocio.
Cada agregado tiene una entidad raíz, que es la única que se expone al exterior y a través de la cual se accede a los demás elementos del agregado. Por ejemplo, en el caso de una orden, la entidad raíz sería la propia orden.
El agregado se encarga de mantener su propia consistencia interna, es decir, que todas las reglas de negocio se cumplan dentro de él, y no se permite que se queden en un estado inconsistente.
En el caso de una orden, la raíz del agregado es la orden misma, y dentro de ella pueden estar los detalles de los productos, las cantidades, etcétera, pero todo se gestiona a través de la orden.
Así, los agregados ayudan a mantener la integridad y la coherencia del modelo.

Separación de Capas

Capa de Dominio
Modelo y Reglas: Aquí se definen las entidades, los agregados, los objetos de valor y las reglas de negocio. Es el corazón del dominio, donde reside la lógica que representa las reglas del negocio.
Capa de Aplicación
Orquestación de Casos de Uso: Aquí se coordinan las operaciones que se deben realizar, pero sin contener lógica de negocio. Su función es orquestar el flujo de trabajo y los casos de uso.
Capa de Infraestructura
Persistencia y Comunicación: Se encarga de la persistencia de datos, como bases de datos, y de las comunicaciones, como HTTP o mensajería.

Síntesis del Modelo de Dominio

La programación orientada a objetos aplicada al domain-problem mapping permite construir modelos de software que representan de forma clara y estructurada un dominio real.
A partir de la identificación de entidades, relaciones y reglas de negocio, se define un modelo donde cada componente tiene una responsabilidad específica.
A nivel de diseño de dominio, la identificación de entidades y casos de uso, junto con el uso de invariantes, agregados y servicios de dominio, permite asegurar consistencia, claridad y correcta distribución de responsabilidades.
Finalmente, la separación en capas (dominio, aplicación, infraestructura) organiza el sistema de forma que el dominio concentra la lógica de negocio, la aplicación coordina los casos de uso y la infraestructura resuelve los aspectos técnicos.
De esta manera, el sistema resulta coherente, mantenible y alineado con el problema real que busca resolver.

Goal of “domain-problem mapping”

Turn a real-world problem (domain) into a software model
Ubiquitous language: shared terms with stakeholders (Order, Customer, Money, Stock).
Concepts → types: entities, value objects, domain services, aggregates.
Rules → invariants: conditions that must always hold.
Use cases → application layer: system operations (place order, pay, cancel).

Essential OOP concepts

Abstraction: keep what matters; model behavior + responsibilities, not everything.
Encapsulation: protect state; only allow changes through methods that enforce rules.
Inheritance: reuse by specialization (“is-a”). Use carefully; composition is often better.
Polymorphism: program to interfaces; swap implementations (Strategy, PaymentMethod).
Composition: build objects from other objects (“has-a”), typically more flexible.

Common design principles you’ll see in good solutions:

SRP (Single Responsibility Principle): one primary reason for a class to change.
OCP (Open/Closed Principle): open for extension, closed for modification.
DIP (Dependency Inversion Principle): depend on abstractions, not concretions.

Additional Java OOP concepts

Classes and objects: a class defines structure/behavior; an object is an instance.
Superclass / Subclass: inheritance via extends (“is-a” relationship).
Inheritance: reuse/extend behavior; avoid deep hierarchies unless they clearly help.
super: reference to the superclass (call constructors/methods):

class Base { Base(int x) {} void hello() {} }
class Child extends Base {
  Child() { super(1); }
  @Override void hello() { super.hello(); }
}

Abstract class: cannot be instantiated; can hold state + abstract/concrete methods.
final class: cannot be extended.
final method: cannot be overridden.
final variable: cannot be reassigned (note: referenced objects may still be mutable).
Interfaces (capabilities): model capabilities/contracts via implements:

interface Payable {
  void pay();
  default boolean isPayable() { return true; } // default method
}
class CardPayment implements Payable {
  @Override public void pay() {}
}

Default method (default): an interface method with an implementation (useful for API evolution).
Overloading: same name, different parameter list (signature) in the same class.
Overriding: a subclass redefines a superclass/interface method (@Override).

class Printer {
  void print(String s) {}      // overloading
  void print(int n) {}         // overloading
}
class A { void run() {} }
class B extends A { @Override void run() {} } // overriding

Casting:
Upcast: safe, implicit (B → A).
Downcast: explicit, can fail at runtime (use instanceof).

A a = new B();          // upcast
if (a instanceof B b) { // pattern matching (Java 16+)
  b.run();              // safe downcast
}

Inner classes:
Non-static inner: holds a reference to the outer instance.
Static nested: behaves more like a regular nested type.
Anonymous classes: inline implementations (common pre-lambdas):

Runnable r = new Runnable() {
  @Override public void run() {}
};

Variable scopes:
Local: inside a method/block.
Instance: non-static fields (per object).
Class (static): shared across instances.
Access: private, protected, package-private, public.
Mutable vs immutable:
String is immutable; StringBuilder is mutable.
Collections are often mutable (ArrayList) unless wrapped/created immutable.
Cloning: clone() is often tricky (shallow copies, awkward contract).
Prefer copy constructors, factories, or explicit copying.

class User {
  final String name;
  User(String name) { this.name = name; }
  User(User other) { this.name = other.name; } // copy constructor
}

Quick mapping workflow

Nouns → class candidates: Order, Customer, Product, Money.
Verbs → methods/use cases: placeOrder, pay, cancel, reserveStock.
Classify types:
Entity: has identity + lifecycle (Order).
Value Object: immutable, compared by value (Money).
Domain Service: logic that doesn’t naturally belong to a single entity (PricingService).
Invariants (hard business rules):
“A paid order cannot be cancelled.”
“Quantity must be > 0.”
Aggregates:
An aggregate has a root (e.g. Order) that protects internal consistency.
Separate layers:
Domain: model + rules.
Application: orchestrates use cases.
Infrastructure: persistence, HTTP, messaging.

Domain example: Orders
Value Object: Money (immutable)

public record Money(double amount, String currency) {
  public Money {
    if (amount < 0) throw new IllegalArgumentException("amount < 0");
    if (currency == null) throw new IllegalArgumentException("currency required");
  }
  Money add(Money o) {
    if (!currency.equals(o.currency)) throw new IllegalArgumentException("currency mismatch");
    return new Money(amount + o.amount, currency);
  }
}

Immutability (@Value) prevents “half-valid” states.
Validation in the constructor enforces invariants early.
Entity + Aggregate Root: Order

public class Order {
  enum Status { DRAFT, PAID, CANCELLED }
  private Status status = Status.DRAFT;

  void addLine(int qty) {
    if (status != Status.DRAFT) throw new IllegalStateException("only DRAFT");
    if (qty <= 0) throw new IllegalArgumentException("qty <= 0");
  }
  void pay()    { if (status == Status.CANCELLED) throw new IllegalStateException(); status = Status.PAID; }
  void cancel() { if (status == Status.PAID)      throw new IllegalStateException(); status = Status.CANCELLED; }
}

Encapsulation: state changes only via rule-checking methods.
Invariants: enforced in addLine, cancel.
Aggregate root: Order controls consistency of lines and status.

Application layer + REST

@Service
class PlaceOrderService {
  UUID place(PlaceOrderCommand cmd) { return UUID.randomUUID(); } // build+save omitted
}

public record PlaceOrderCommand(UUID customerId, List<Line> lines) {
    public record Line(UUID productId, int quantity, Money unitPrice) {}
}

public interface OrderRepository {
    void save(Order order);
    Optional<Order> findById(UUID id);
}

@RestController
@RequestMapping("/orders")
public class OrderController {
  private final PlaceOrderService placeOrderService;
  public OrderController(PlaceOrderService s) { this.placeOrderService = s; }

  @PostMapping
  ResponseEntity<Void> place(@RequestBody PlaceOrderCommand body) {
    UUID id = placeOrderService.place(body);
    return ResponseEntity.created(URI.create("/orders/" + id)).build();
  }
}

The domain should not depend on Spring.
Spring stays in API/application/infrastructure.

Common mapping mistakes

Anemic domain model: entities are just getters/setters; rules live elsewhere.
Inheritance by default: using inheritance where composition fits better.
Validation only in controllers: invariants must live in the domain too.
DB-driven modeling: modeling tables first instead of business rules and behavior.

Final thoughts: From OOP to a meaningful domain model

At first glance, Object-Oriented Programming concepts (abstraction, encapsulation, inheritance, polymorphism) may seem like isolated technical tools. However, their real value appears when they are used together to model a real-world problem with clarity and precision.

Domain-problem mapping is where everything connects:

OOP gives structure → classes, interfaces, and relationships.
Domain modeling gives meaning → entities, value objects, and business rules.
Application layers give direction → use cases and system behavior.

When applied correctly, this approach leads to software that is:

Expressive: the code speaks the same language as the business (ubiquitous language).
Robust: invariants protect the system from invalid states.
Flexible: changes in requirements can be handled through well-defined abstractions.
Maintainable: responsibilities are clear and isolated.

The key shift is this:

We are not just writing code, we are modeling reality through software.

This means:

Classes are not just data holders, but guardians of rules.
Methods are not just actions, but business behaviors.
Design is not accidental, but intentional and aligned with the domain.

Finally, frameworks like Spring Boot are only tools to expose and run our system (REST APIs, persistence, etc.), but they should never define the core of our design. The domain remains independent, clean, and focused on business logic.

🟦 Technical Testing
Technical testing focuses on validating the internal behavior of the system.
It includes automated testing, performance testing, and security testing.

🟦 Unit Test
A Unit Test is a test that validates a minimal unit of code in isolation.
In Java, it typically tests a method or a class.
It runs without depending on databases, APIs, or other external systems.
Tools such as JUnit and Mockito are commonly used.

🟦 Black Box Testing
Black Box Testing validates the system without knowledge of its internal implementation.
It focuses on inputs and outputs.
It simulates user behavior.
It does not require access to the code.

🟦 White Box Testing
White Box Testing validates the system with knowledge of the internal code.
It focuses on logic, structures, and flows.
It allows covering specific code paths and scenarios.

🟦 Objectives of Black Box and White Box Testing
The objective of Black Box Testing is to validate functionality from the user’s perspective.
The objective of White Box Testing is to ensure correct internal implementation.

Black Box Testing does not require knowledge of the code, while White Box Testing does.
Black Box focuses on external behavior, while White Box focuses on internal logic.
Black Box is closer to the user, while White Box is closer to the developer.

🟦 Integration Test
An Integration Test is a test that validates the interaction between multiple components of the system.
Unlike Unit Testing, it does not test a single isolated unit, but rather how components work together.

🟦 Differences Between Integration Test and Unit Test
A Unit Test validates an isolated unit, while an Integration Test validates multiple components working together.
A Unit Test uses mocks to isolate dependencies, while an Integration Test uses real implementations.
A Unit Test detects errors in individual logic, while an Integration Test detects errors in interactions between modules.

🟦 SoapUI
SoapUI is a tool for testing web services.
It allows testing both SOAP and REST APIs.
It is useful for functional and integration testing.

🟦 Postman
Postman is a tool for testing REST APIs.
It allows sending HTTP requests and analyzing responses.

🟦 JMeter
Apache JMeter is a performance testing tool.
It allows simulating multiple concurrent users.
It is used for load and stress testing.
It helps detect system bottlenecks.

🟦 Mocking
Mocking is a technique that simulates the behavior of external dependencies.
It allows isolating the unit being tested.

🟦 Stubbing
Stubbing consists of defining predictable responses for specific methods.
It is used to control the behavior of dependencies.
It does not validate interactions, it only returns predefined data.

🟦 Spying
Spying allows observing the real behavior of an object.
It is useful when you want to monitor without fully replacing the object.

🟦 Difference Between Mocking, Spying and Stubbing
Mocking fully simulates an object and allows verifying interactions.
Stubbing only defines responses without validating method calls.
Spying uses real objects but allows observing their behavior.

Mocking is used for full isolation,
stubbing for controlling data,
and spying for monitoring execution.

🟦 TDD (Test Driven Development)
TDD is a development practice where tests are written before the actual code.
The TDD cycle consists of three steps: Red, Green, and Refactor.
Red means writing a failing test.
Green means writing the minimum code required to pass the test.
Refactor means improving the code without breaking the tests.

🟦 BDD (Behavior Driven Development)
BDD is an evolution of TDD focused on system behavior.
It centers on how the user interacts with the system.
It uses natural language to define scenarios.
It facilitates communication between business and technology.
It uses structures such as Given, When, Then.
The main objective is to ensure the system meets the expected business behavior.

🟦 ATDD (Acceptance Test Driven Development)
ATDD is a practice where acceptance tests are defined before development.
It focuses on validating requirements from the beginning.

🟦 Difference Between TDD, BDD and ATDD
TDD focuses on code and small units.
BDD focuses on system behavior.
ATDD focuses on business acceptance criteria.
TDD is technical, while BDD and ATDD connect more closely with the business.

🟦 Load Testing
Load Testing is a type of performance testing that evaluates how the system behaves under an expected user load.
It helps verify whether the system can handle normal usage without degradation.
Metrics such as response time, throughput, and resource usage are measured.
It is key for validating system stability before production.

🟦 Stability Testing
Stability Testing evaluates whether the system can continue operating correctly over an extended period of time.
It is performed under a constant load.
It helps detect memory leaks or progressive degradation.
It is important for systems that must remain continuously available.

🟦 Stress Testing
Stress Testing evaluates the system beyond its normal limits.
The load is increased until the system fails.
It helps identify the breaking point.
It also helps understand how the system recovers from failures.

🟦 Ad Hoc Testing
Ad Hoc Testing is an unstructured type of testing.
It does not follow predefined test cases.
It relies on the tester’s experience and intuition.
It is useful for discovering unexpected defects.

🟦 Concepts and Differences Between Load, Stress and Stability Testing
Load Testing evaluates behavior under normal load conditions.
Stress Testing evaluates behavior under extreme conditions.
Stability Testing evaluates behavior over a long period of time.

🟦 Clean Code
Clean Code is the practice of writing code that is clear, simple, and easy to maintain.

🟦 Clean Code Architecture
Clean Code Architecture aims to organize the system in a modular and decoupled way.
It is based on separation of responsibilities.
It promotes low coupling and high cohesion.

🟦 Relation Between Clean Code and Architecture
Clean Code applies at the code level.
Architecture applies at the system level.

🟦 Things to Avoid
Long and complex methods should be avoided.
Unclear naming should be avoided.
Code duplication should be avoided.

🟦 Writing Non-Testable Code
Non-testable code has rigid dependencies.
It does not allow isolating components.

🟦 Code Smell
A Code Smell is an indication that something is wrong in the code.
It is not a bug, but it signals a design problem.
Examples include long methods or duplicated code.

🟦 SOLID Principles
SOLID is a set of design principles in object-oriented programming.
It improves maintainability and scalability.
It reduces coupling.

🟦 Single Responsibility Principle
A class should have only one responsibility.

🟦 Open/Closed Principle
Code should be open for extension but closed for modification.
It allows adding functionality without changing existing code.

🟦 Liskov Substitution Principle
Child classes should be able to replace parent classes.
They must not break expected behavior.

🟦 Interface Segregation Principle
Specific interfaces should be created.
It avoids large and unnecessary interfaces.

🟦 Dependency Inversion Principle
Dependencies should rely on abstractions, not implementations.
It facilitates testing and decoupling.