Forem: Narednra Reddy Yadama

🚀 Auto-Configuration in Spring Boot ⚡

Narednra Reddy Yadama — Mon, 20 Oct 2025 14:20:03 +0000

👉 Spring Boot AutoConfiguration = less manual config + faster development.

When we call SpringApplication.run(..,..) from our main class (which also serves as the Configuration class) — a lot happens behind the scenes 👀

One of the most powerful operations is AutoConfiguration — where Spring Boot automatically configures beans based on the starters/jars you’ve added to your classpath.

Here’s how it actually works 👇

🧩 AutoConfiguration Process (Step by Step)

🔍 The IoC container scans all JARs in the classpath to find a file named spring.factories.
📂 It locates this file in multiple JARs.

🧠 Inside each, it looks for the key:
org.springframework.boot.autoconfigure.EnableAutoConfiguration
⚙️ In the spring-boot-autoconfigure-.jar, it collects all the values mapped to that key — which are pre-built configuration classes such as:

👇
org.springframework.boot.autoconfigure.EnableAutoConfiguration=/,
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,
org.springframework.boot.autoconfigure.jdbc.JdbcTemplateAutoConfiguration,
org.springframework.boot.autoconfigure.jdbc.XADataSourceAutoConfiguration,
org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfig

🔁 Spring then processes each of these configuration classes (including their nested and imported @Configuration classes).
🧱 It executes all their @bean methods to create ready-to-use beans — like HikariDataSource, JdbcTemplate, etc.

That’s how Spring Boot gives you so much out-of-the-box power 🔥

🛑 Can We Disable Specific AutoConfigurations?

✅ Absolutely.
Even if you’ve added certain starters, you can stop specific auto-configurations by using the exclude parameter in @SpringBootApplication:

Example 👇
@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class,
JdbcTemplateAutoConfiguration.class })
public class BootProjRealtimeDiAutoConfigurationApplication {
// ...
...
}

💬 In short:
Spring Boot AutoConfiguration = less manual config + faster development.
And when you need control, Spring gives it back — effortlessly. 🙌

🚀 Bridging Full-Stack Java + AI/ML + RAG (Retrieval Augmented Generation)

Narednra Reddy Yadama — Thu, 16 Oct 2025 13:41:58 +0000

As a Java Full-Stack Developer, I’ve spent years building robust backend systems using Spring Boot, microservices, and reactive stacks. But lately, I’ve been diving headfirst into combining AI/ML + RAG architectures to build smarter apps.

Here’s what I’m building now:
• ⚙️ A proof-of-concept AI-powered knowledge assistant that uses RAG to fetch relevant snippets from large document corpora, then uses a Transformer model to synthesize answers.
• Backend is in Java (Spring Boot, WebFlux), with integrations into vector stores / embeddings (e.g. FAISS, Pinecone) and LLM APIs.
• On the frontend, I’m prototyping a React UI that supports conversational querying + context retention.

Why this matters:
• Many systems today just hand over raw LLM responses; by combining retrieval + reasoning, we reduce hallucinations and increase relevance.
• This fusion (Java full-stack + AI + RAG) is rare and powerful — it’s where modern enterprise applications are heading.

What I’m learning next:
• Fine-tuning domain-specific embeddings
• Better context-window management
• Efficient caching & real-time updates

📡 𝗝𝗮𝘃𝗮 𝗶𝗻 𝗧𝗲𝗹𝗲𝗰𝗼𝗺: 𝗵𝗮𝗻𝗱𝗹𝗶𝗻𝗴 𝗺𝗶𝗹𝗹𝗶𝗼𝗻𝘀 𝗼𝗳 𝗰𝗼𝗻𝗰𝘂𝗿𝗿𝗲𝗻𝘁 𝘀𝗲𝘀𝘀𝗶𝗼𝗻𝘀 (𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗺𝗲𝗹𝘁𝗶𝗻𝗴)

Narednra Reddy Yadama — Thu, 16 Oct 2025 13:36:39 +0000

Telco traffic is spiky. Stateful. Ruthless.

Your backend still has to say “200 OK”—every time.

Here’s the Java-first blueprint I’d ship 👇

◾ Event-driven I/O

Netty / Vert.x for long-lived TCP/TLS, WebSocket, HTTP/2. Zero blocking on the hot path.

◾ Shard the session plane

Partition by IMSI/MSISDN/call-id. Sticky routing keeps a session on one shard.

◾ State out of process

Redis/Aerospike for hot session maps; Cassandra/Scylla for durable CDRs. TTL everything.

◾ Protocols without surprises

SIP/IMS timers, retransmits; Diameter watchdogs (DWR/DWA), CCR/CCA credit loops; 5G SBA over HTTP/2 with CBOR.

◾ Backpressure everywhere

Bounded queues, token buckets per peer, circuit breakers (Resilience4j). Shed low-priority first.

◾ Exactly-once UX

At-least-once on the wire, de-dupe with idempotency keys at the edge.

◾ JVM tuning that matters

G1/ZGC, small regions, off-heap ByteBufs, reuse objects. One event loop per core; pin shards to NUMA.

◾ Virtual threads (Java 21)

Great for orchestration and control-plane RPCs; keep data-plane on non-blocking I/O.

◾ Observability like a carrier

OpenTelemetry trace with call-id baggage; Micrometer for per-shard CPU/GC/queue depth; p95 setup, p99 in-call, drop rate.

◾ Failure drills

Kill a shard → rebuild from Kafka compacted topics. Throttle a downstream → graceful degrade via local policy cache.

Latency budget (single region target)

Gateway 5–10 ms → Session logic 10–20 ms → Policy/credit 10–30 ms → Egress 10–20 ms

➡ End-to-end <150 ms p95 even under spike.

Takeaway

Telecom scale isn’t magic. It’s event-driven Java, externalized state, ruthless backpressure, and SLOs you actually enforce.

Java Developer RoadMap

Narednra Reddy Yadama — Tue, 14 Oct 2025 00:27:27 +0000

🔐 𝗠𝘂𝗹𝘁𝗶-𝗣𝗮𝗿𝘁𝘆 𝗖𝗼𝗺𝗽𝘂𝘁𝗮𝘁𝗶𝗼𝗻 (𝗠𝗣𝗖) 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸𝘀 𝗪𝗿𝗶𝘁𝘁𝗲𝗻 𝗶𝗻 𝗝𝗮𝘃𝗮 — 𝗽𝗿𝗶𝘃𝗮𝗰𝘆 𝘁𝗵𝗿𝗼𝘂𝗴𝗵 𝗺𝗮𝘁𝗵, 𝗻𝗼𝘁 𝗽𝗿𝗼𝗺𝗶𝘀𝗲𝘀

Narednra Reddy Yadama — Mon, 13 Oct 2025 12:58:24 +0000

When your app needs collaboration without disclosure think joint risk analysis, cross-bank fraud detection, or federated ML training , you reach for MPC.

Here’s how Java quietly powers real MPC systems 👇

◾ What is MPC?

Multi-party computation lets multiple entities compute a function over their private data without revealing their inputs.

Example:

Two banks detect fraud trends together without sharing customer data.

Or multiple hospitals train a shared AI model without leaking patient info.

◾ Key Java Frameworks

1️⃣ FRESCO (Flexible, REliable, Secure COmputation)

The most mature open-source Java MPC framework maintained by the Alexandra Institute.

Designed for extensible backends: you can plug in your own crypto primitives or field sizes.

Provides “builder pattern” APIs → write MPC like normal Java math.

Numeric x = builder.input(mySecret, 1);

Numeric y = builder.input(theirSecret, 2);

DRes sum = builder.numeric().add(x, y);

Backends include: SPDZ2k, Shamir secret sharing, and dummy protocols for testing.

Used in academic research and prototype deployments (finance, medtech).

2️⃣ EMP-Java (Experimental MPC Port)

A partial Java port from the EMP toolkit family.

Focuses on two-party computation (garbled circuits, OT protocols).

Useful for low-latency benchmarking or when your stack is JVM-based but needs EMP-style semantics.

3️⃣ JavaMPC (Research Implementations)

Some university and enterprise prototypes (not full frameworks):

Scapi (Secure Computation API) – hybrid of Java & C++ JNI, implementing garbled circuits, oblivious transfer, etc.

Often used in education and academic benchmarks.

◾ Architecture Pattern (How Java Fits MPC)

Coordinator Node (Java) — defines computation graph, distributes shares/circuits.

Participants (Java microservices) — compute partial shares locally.

Aggregator — collects results, verifies commitments, assembles the output.

🔧 Java advantages:

Portable JVM deployment (cross-org collaboration → no container hell).

Stable crypto libraries (BouncyCastle, SCAPI).

◾ Performance Insights

◾ Java GC tuning is critical: MPC = small objects × billions. Use G1/ZGC.

◾ Favor primitive arrays over boxed types for arithmetic-heavy protocols.

◾ Keep I/O async — virtual threads (Java 21) shine for network-heavy protocols.

💡 Takeaway

MPC isn’t only for cryptographers anymore.

With frameworks like FRESCO and SCAPI, Java makes privacy-preserving collaboration deployable at enterprise scale.

🚚 𝗟𝗼𝗴𝗶𝘀𝘁𝗶𝗰𝘀 𝗥𝗼𝘂𝘁𝗲 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 — 𝗯𝘂𝗶𝗹𝘁 (𝘀𝗮𝗻𝗲𝗹𝘆) 𝘄𝗶𝘁𝗵 𝗝𝗮𝘃𝗮

Narednra Reddy Yadama — Fri, 10 Oct 2025 12:06:17 +0000

Same fleet. Same cities. Less miles. More on-time. Lower fuel.

That’s not magic — it’s constraints + streaming + smart heuristics.

Here’s the blueprint I’d ship today 👇

◾ Core problems you’ll solve

◾ VRP flavors: CVRP, VRPTW, multi-depot, pickup-&-delivery, cold-chain

◾ Hard constraints: capacity, time windows, driver shifts, service times

◾ Soft goals: distance, on-time %, CO₂, tolls, SLA penalties, fairness

◾ Java-first architecture

◾ Ingest → Kafka: orders, live GPS pings, traffic, depot status

◾ Store → Postgres (orders & depots), Redis (hot state), ClickHouse (historical KPIs)

◾ Routing graph → GraphHopper/OSRM (road speeds, truck profiles, turn costs)

◾ Optimizer → Java 21 service using OptaPlanner or OR-Tools (Java API)

◾ Stream brain → Flink/Kafka Streams for ETA updates & re-optimization triggers

◾ API/Gateway → Spring Boot / Quarkus (gRPC/REST) with SSE/WebSockets for live boards

◾ Obs → Micrometer + Prometheus + OpenTelemetry (per-route KPIs & solver stats)

◾ Optimization loop (fast & practical)

Build problem: vehicles, jobs, time windows, distances from routing graph

Seed solution: nearest-neighbor / sweep / savings heuristic

Publish: assign routes; stream ETAs to ops & drivers

React: when traffic or delays hit → incremental re-optimize affected region only

◾ Real-time realities (what actually works)

◾ Rolling horizon: lock near-term stops, optimize the tail — drivers don’t like teleporting routes

◾ Regional shards: city or depot partitions keep solve times predictable

◾ SLA safety: deadline guardrails override “shortest path” when needed

◾ What-if: sandbox a copy of live data for planners (no impact on drivers)

◾ Latency targets

◾ Small batch (≤200 stops/depot) initial plan: < 20–60s

◾ Incremental re-plan (spill, traffic, no-show): < 2–5s

◾ ETA refresh pipeline end-to-end: < 1s

Keep the UI streaming partial results — progress beats silence.

◾ Java tuning cheatsheet

◾ Java 21 virtual threads around IO (maps, DB, telemetry)

◾ G1/ZGC with small regions; avoid large object churn in scorers

◾ Precompute time-dependent travel times; avoid calling routing server inside inner loops

◾ “Planner overrides needed” — should trend down as the system learns

◾ Rollout in 4 sprints

Static nightly plans + live ETA dashboard

Mid-day incremental re-opt (traffic/incidents)

Driver app hooks (ack, proof-of-delivery) + SLA penalties in score

Multi-depot balancing, what-if simulator, cost/CO₂ optimization

Takeaway

Great logistics isn’t “solve once.”

It’s a Java loop that senses, decides, and adapts — all day, every day.

🚀 Spring Boot vs Spring Framework — Which One Should You Choose?

Narednra Reddy Yadama — Fri, 10 Oct 2025 11:59:12 +0000

Choosing the right framework isn’t just technical—it’s strategic. Here’s how to pick the one that fits your project like a glove 👇

🌿 Spring Framework The OG. Powerful, flexible, and enterprise-ready.
✅ Manual configuration
✅ Fine-grained control
✅ Ideal for legacy systems & complex architectures

🔧 Use it when:
▫️ You need full control over every layer
▫️ You're integrating with older tech stacks
▫️ You’re building a large-scale monolith or hybrid system

⚡ Spring Boot The fast lane to production. Opinionated, modern, and microservice-friendly.

✅ Auto-configuration
✅ Embedded servers (Tomcat, Jetty)
✅ Production-ready with Actuator & metrics

🔧 Use it when:
▫️ You want rapid development
▫️ You're building REST APIs or microservices
▫️ You prefer convention over configuration

🔥 𝗔𝗱-𝗧𝗲𝗰𝗵 𝗔𝘂𝗰𝘁𝗶𝗼𝗻 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗮𝘁 𝗦𝗰𝗮𝗹𝗲 — 𝗕𝘂𝗶𝗹𝘁 𝗼𝗻 𝗝𝗮𝘃𝗮 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀

Narednra Reddy Yadama — Thu, 09 Oct 2025 11:31:58 +0000

Every time you open an app or a website, an invisible war happens.

Hundreds of advertisers compete — and all of it ends in under 120 milliseconds.

That’s real-time bidding (RTB).

And Java? Still one of the best tools to power it.

◾ The Challenge

◾ Handle 1M+ bid requests per second (QPS)

◾ Complete auction logic, scoring, pricing, and response

◾ Maintain latency <100ms end-to-end

◾ Avoid revenue leaks from concurrency, GC, or network lag

◾ System Blueprint

1️⃣ Ingress Layer (Bid Gateway)

Built using Netty or Vert.x — lightweight, async, blazing fast.

Accepts OpenRTB 2.x / 3.x JSON bid requests from SSPs or exchanges.

Parses + validates payloads, then publishes to internal Kafka topic (bids.incoming).

2️⃣ Enrichment & Targeting Service

Microservice in Spring Boot + Reactor or Micronaut.

Adds geo, device, user segments, campaign eligibility.

Fetches feature vectors from Redis or Aerospike in <10ms.

3️⃣ Real-Time Auction Service (The Heart)

Written in Java with low-GC tuning (ZGC / Shenandoah).

Implements second-price (Vickrey) or first-price auctions.

Filters 1000+ bids → sorts by eCPM → applies business constraints (budget, pacing, frequency caps).

Uses in-memory priority queues or skip-lists for O(log n) selections.

Publishes the winning bid to Kafka (bids.won) and returns the ad markup immediately.

4️⃣ Budget & Pacing Engine

Tracks spend per campaign / advertiser in Redis + Kafka Streams.

Prevents overspending by reserving budgets atomically.

Supports real-time pacing (budget/time) with leaky bucket logic.

5️⃣ Analytics & Feedback Loop

Impression, click, conversion events flow into Kafka → Flink for aggregation.

ML models update bid multipliers in near-real time (CTR, CVR predictions).

Model outputs stored in feature store (Feast / Redis / Cassandra).

◾ Key Tech Stack

Java 21 (virtual threads for concurrency)

Spring Boot / Micronaut / Quarkus for microservices

Kafka + Flink for streaming and feedback

Redis / Aerospike for ultra-low latency key lookups

gRPC for internal service calls

ClickHouse / Pinot for analytics

Prometheus + Grafana + OpenTelemetry for observability

◾ Performance Tricks

◾ Keep auction logic pure in-memory — no DB calls on critical path

◾ Use object pooling to avoid GC pauses

◾ Co-locate data (geo + campaign data in RAM)

◾ Batch outbound responses using Netty channels

◾ Fraud detection hooks every 10ms (bot, domain spoofing, invalid traffic)

◾ Fail open (show fallback ad) — never blank screen

💡 Takeaway:

The fastest ad auction wins the dollar.

Java still dominates here , not because it’s fancy, but because it’s predictable, tunable, and fast.

🚨𝗙𝗶𝗻𝗮𝗻𝗰𝗶𝗮𝗹 𝗙𝗿𝗮𝘂𝗱 𝗗𝗲𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀 𝗶𝗻 𝗝𝗮𝘃𝗮 — 𝗥𝗲𝗮𝗹-𝘁𝗶𝗺𝗲 𝗗𝗲𝗳𝗲𝗻𝘀𝗲 𝗳𝗼𝗿 𝘁𝗵𝗲 𝗠𝗼𝗱𝗲𝗿𝗻 𝗙𝗶𝗻𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸

Narednra Reddy Yadama — Thu, 09 Oct 2025 10:41:20 +0000

Fraud doesn’t sleep. Your detection system shouldn’t either.

Here’s how Java powers real-time pipelines that stop fraud before it drains your balance 👇

◾ Core Objective
Detect, score, and act — all under 250 ms.
Because if your fraud engine lags, it’s already too late.

◾ Architecture Overview
1️⃣ Data Ingestion (Streaming Layer)
Kafka → Streams all transaction, login, device, and KYC events.
Schema-registry-based contracts ensure every producer speaks the same language.
Enrichment: device fingerprint, geolocation, velocity tracking, behavioral history.

2️⃣ Stream Processing (Real-time Risk Engine)
Built in Java + Apache Flink / Kafka Streams.
Each transaction runs through:
◾ rule-based filters (blacklists, velocity limits)
◾ statistical features (amount deviation, merchant risk)
◾ machine learning models (served via TensorFlow Java API or ONNX Runtime)
CEP (Complex Event Processing) detects suspicious patterns like:
“3 cards, same IP, 5 mins apart” or “sudden cross-border spike”.

3️⃣ Model Serving Layer
Embeds trained models (XGBoost, LSTM) into the stream pipeline.
Real-time feature store (Redis, Cassandra, or HBase) keeps user behavior context.
Each transaction gets a fraud probability score + risk tag (low/medium/high).

4️⃣ Decision & Action Layer
Scoring rules via Drools or custom DSL → interpretable thresholds.
Low-risk → auto-approve
Medium → queue for human review
High → instant block + notification + case logging

5️⃣ Feedback Loop
Analysts flag false positives → feedback re-trains the model.
Daily aggregations → pattern updates in batch via Spark / Flink nightly jobs.

◾ Why Java Fits
Concurrency without chaos: Reactor / Vert.x for parallel fraud checks.
JVM maturity: proven stability for 24×7 banking loads.
Library power: integrate ML, CEP, stream, and rule engines under one runtime.
Battle-tested in BFSI: used in production by Stripe, PayPal, and Revolut-scale stacks.
◾ Engineering Tips
◾ Keep feature computations idempotent — fraud data must be traceable.
◾ Build “explainability hooks” — auditors love transparency.
◾ Monitor model drift daily.
◾ Latency budget → 100ms ingest, 100ms scoring, 50ms response.
◾ Always log “why a transaction was blocked.”

💡 Takeaway
A great fraud pipeline isn’t just about flagging bad actors —
It’s about doing it fast, fair, and explainably.
Java’s reliability makes sure the system runs when stakes are highest.

𝗕𝗶𝗴 𝗗𝗮𝘁𝗮 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲 𝗖𝗵𝗲𝗮𝘁𝘀𝗵𝗲𝗲𝘁: 𝗔𝗪𝗦, 𝗔𝘇𝘂𝗿𝗲, 𝗮𝗻𝗱 𝗚𝗖𝗣

Narednra Reddy Yadama — Wed, 08 Oct 2025 13:43:21 +0000

In today’s data-driven world, cloud-native big data pipelines are essential for extracting insights and maintaining a competitive edge.

Here’s a concise breakdown of key components across AWS, Azure, and GCP:

𝟭. 𝗗𝗮𝘁𝗮 𝗜𝗻𝗴𝗲𝘀𝘁𝗶𝗼𝗻:

AWS: Kinesis (real-time), AWS Data Pipeline (managed workflows)
Azure: Event Hubs (real-time streaming), Data Factory (ETL)
GCP: Pub/Sub (real-time), Dataflow (batch & stream processing)

𝟮. 𝗗𝗮𝘁𝗮 𝗟𝗮𝗸𝗲:

AWS: S3 with Lake Formation for secure data lakes
Azure: Azure Data Lake Storage (ADLS), integrates with HDInsight & Synapse
GCP: Google Cloud Storage (GCS) with BigLake for unified data management

𝟯. 𝗖𝗼𝗺𝗽𝘂𝘁𝗲 & 𝗣𝗿𝗼𝗰𝗲𝘀𝘀𝗶𝗻𝗴

AWS: EMR (managed Hadoop/Spark), Glue (serverless data integration)
Azure: Databricks (Spark-based analytics), HDInsight (Hadoop)
GCP: Dataproc (managed Spark/Hadoop), Dataflow (Apache Beam-based processing)

𝟰. 𝗗𝗮𝘁𝗮 𝗪𝗮𝗿𝗲𝗵𝗼𝘂𝘀𝗶𝗻𝗴

AWS: Redshift – scalable, high-performance data warehousing
Azure: Synapse Analytics – combines SQL Data Warehouse & big data processing
GCP: BigQuery – serverless, highly scalable, cost-effective analytics

𝟱. 𝗕𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗜𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝗰𝗲 & 𝗩𝗶𝘀𝘂𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻

AWS: QuickSight – scalable BI & reporting
Azure: Power BI – deeply integrated with Microsoft ecosystem
GCP: Looker – flexible data visualization & analytics

Each cloud provider has unique strengths.

Selecting the right combination of ingestion, storage, compute, and analytics tools is key to building scalable, cost-effective big data pipelines.

Whether handling real-time streaming or deep data warehousing or batch processing, choosing wisely can optimize both efficiency and costs.

The AI panic is turning a generation of professionals into carpenters with hammers the size of cars.

Narednra Reddy Yadama — Wed, 08 Oct 2025 12:16:20 +0000

They see the hype.
Fear that their jobs are at risk.
Spend months mastering complex tools they may never need.

Now, everything looks like a nail.

This is moving backward.

MCP (you can think of it like API, or HTTP for AI agents) is a perfect example

I always tell my students:
The value isn’t in the tool.
It’s in the problem.

Don’t start with the tech.
Start with the pain.

Do you want to thrive in the AI age and ALWAYS stay relevant? SOLVE PROBLEMS.

People pay you for solving their problems, not for the catalogue of tools you have in your bag!

Find a real problem that needs a better solution (don't worry, AI or not, we're never running out of problems).
Then — and only then — find the right tool.

Often, the simplest one wins.

The future belongs to problem solvers.

Image Credit: Eduardo Ordax

🧨 What is Deadlock?

Narednra Reddy Yadama — Wed, 08 Oct 2025 12:11:45 +0000

A deadlock occurs when two or more threads are waiting for each other’s locks, and none can proceed. It’s like two people holding one key each, refusing to give theirs up until they get the other’s. Result? Permanent standstill.

🔁 The 4 Deadlock Conditions (Coffman Conditions)
▫️ Deadlock can only happen if all four of these are true:
▫️ Mutual Exclusion – Only one thread can hold a lock at a time
▫️ Hold and Wait – A thread holds one lock and waits for another
▫️ No Preemption – Locks can’t be forcibly taken away
▫️ Circular Wait – A cycle of threads waiting on each other

🧪 Code Example: Deadlock in Action

class DeadlockDemo {
final Object lockA = new Object();
final Object lockB = new Object();

void methodA() {
synchronized (lockA) {
try { Thread.sleep(100); } catch (InterruptedException e) {}
synchronized (lockB) {
System.out.println("Thread A acquired both locks");
}
}
}

void methodB() {
synchronized (lockB) {
try { Thread.sleep(100); } catch (InterruptedException e) {}
synchronized (lockA) {
System.out.println("Thread B acquired both locks");
}
}
}

public static void main(String[] args) {
DeadlockDemo demo = new DeadlockDemo();

new Thread(demo::methodA).start();
new Thread(demo::methodB).start();
}
}

🧠 What Happens Here?
🔹 Thread A locks lockA, then tries to get lockB
🔹Thread B locks lockB, then tries to get lockA
🔹Both threads are stuck—each waiting for the other to release a lock 💥 Deadlock!

🛡️ How to Prevent Deadlock
✅ Lock Ordering: Always acquire locks in a consistent global order
✅ Try-Lock with Timeout: Use ReentrantLock.tryLock() to avoid indefinite waiting
✅ Avoid Nested Locks: Minimize locking inside other locks
✅ Use Concurrency Utilities: Prefer ExecutorService, ConcurrentHashMap, etc.

🔚 Final Thought
Deadlocks don’t crash your app—they freeze it. They’re sneaky, hard to debug, and often missed in testing. Design defensively, and always think in terms of lock strategy.