Forem: Anwar

Agentic AI: Governance, Guardrails and Security

Anwar — Mon, 06 Apr 2026 05:00:00 +0000

If a standard Chatbot like ChatGPT is like a high-end GPS giving you directions and info, an Agentic AI is the self-driving car that actually turns the wheel. It doesn’t just tell you how to book a flight; it logs into your corporate card, navigates the portal, and buys the ticket. Giving AI the keys without a license, a seatbelt, or a map leads to expensive and sometimes irreversible failures.

Rouge Agentic AI: Real Stories without Safeguards

Air Canada Chatbot (2022) : A chatbot hallucinated a bereavement refund policy that didn’t exist leading to financial and legal consequences. Air Canada argued in court that the chatbot was a "separate legal entity" responsible for its own actions. The British Columbia Civil Resolution Tribunal rejected this, forcing the airline to honor the agent's "offer" and pay damages, So AI outputs can become legally binding statements.

Replit AI Incident (2025) An AI coding agent ignored a code freeze instruction and deleted a production database. Replit’s CEO publicly apologized and had to implement stronger separation between dev/production environments and better enforcement of instructions

Moltbook Exposure (2026): A misconfigured AI-agent platform exposed millions of API keys, enabling prompt injection attacks and data theft. Autonomous systems amplify security failures at scale.

These are few incidents which demonstrate how agentic systems lacking guardrails, governance, and security can cause rapid, autonomous harm, turning powerful tools into vectors for destruction or fraud.

The Three Foundations to build Safe Agentic AI Platforms

Governance is your constitution. It defines the boundaries of autonomy.

Guardrails enforce behavior. It ensures the agent behaves predictably even in unpredictable scenarios.

Security restricts capability. It ensures that even if something goes wrong, the blast radius is limited.

If any one of these fails, it creates unbounded risk.

I. Governance: The Constitution / Policy Layer

It’s the "who, what, and why" of your AI strategy. It also defines the scope of agency and the human-agent social contract. Before building anything, define:

Human-in-the-Loop: What actions are safe to automate, and what requires approval? For instance, an agent may triage 1000 emails but requires a human approval for any transaction exceeding a specific value.
Audit Trails: In an agentic workflow, I don't know why it did that is an unacceptable answer. Governance ensures a persistent audit trail capturing the prompt, the model’s reasoning, decisions, tool it used and the tool output.
Accountability: Defining who is legally and professionally responsible when the agent makes a mistake. Governance aligns AI behavior with corporate, legal and brand standards.

II. Guardrails: Seatbelts / Constraint Layer

Guardrails are the "Operational Layer." They are the real-time enforcement mechanisms that prevent an agent from drifting outside its intended behavioral "latent space".

Semantic Filtering / Input Guardrails: Detect Prompt Injections or malicious intent (e.g., a user trying to trick the AI into ignoring its rules) before they reach the Agent.
Deterministic Validation / Output Guardrails: Prevent the AI from hallucinating facts, leaking sensitive data, or using toxic language. Checking AI generated code or API calls against a set of hard rules (e.g., ensuring a SQL query doesn't contain a DROP TABLE command) before execution.
Action Guardrails: They prevent an agent from executing a command that looks suspicious like Delete All Records, Execute unauthorized, non-compliant trade even if the AI thinks it's a good idea.
Tool Abuse Protection: Prevent agents from chaining tools in unsafe ways.

III. Security: The Infrastructure Layer

Security is the "Hardened Layer." It treats the AI Agent as a Privileged User and applies the principles of Zero Trust.

The Least Privilege: An agent should not have God Mode access to the enterprise. The agent should only access what it absolutely needs nothing more.
Sandboxing: Run agentic actions especially code execution within isolated environments to contain failures. If an agent is compromised, the blast radius is confined to that single container, protecting the broader corporate network.
Egress Control: Hardening the network, ensuring the AI can only talk to approved websites/resources/tools. Restrict where the agent can send data, preventing exfiltration.

Why You Must Set This Up Before You Build

Building an agentic platform without these foundations is like building a skyscraper without a foundation. Organizations that skip this step face:

Financial Loss: From unauthorized or hallucinated transactions.
Reputational Damage: From agents making legally binding promises that the company can't keep.
Security Breaches: From over-permissioned agents being manipulated by external attackers.

Final Thoughts!

Agentic systems don’t operate in clean, isolated environments. Like humans, They operate in the real world i.e. (messy, ambiguous, and adversarial).

The future of AI isn’t defined by how much it can do, but by how safely and reliably it can do it.

Sources and Further Reading

For more insights and detailed overview, please explore the following resources:

AWS Incident Response: SecurityAudit Access

Anwar — Mon, 30 Mar 2026 12:30:00 +0000

In the heat of a security incident, your team needs eyes everywhere. Without the right visibility into permissions, logs, and account activity, teams may struggle to confirm what happened, limit damage, and recover with confidence. That’s exactly where AWS’s SecurityAudit managed IAM policy shines. It’s the read-only detective badge that gives your Incident Response (IR) team instant, safe visibility into your entire AWS environment without letting anyone touch a single configuration.

What is SecurityAudit?

SecurityAudit is an official AWS-managed policy (ARN: arn:aws:iam::aws:policy/SecurityAudit) that delivers broad read-only access to security configuration metadata across dozens of services.

IAM configurations
CloudTrail logs
GuardDuty findings
Security Hub insights
AWS Config rules
Inspector scan results
S3, EC2, KMS metadata

The key principle is simple: Auditing and investigation & no Create, Update, Delete, or Put actions allowed. Just Get*, List*, and Describe* everywhere you need them.

Why Use SecurityAudit for Incident Response?

The Principle of Least Privilege: During an active incident, the last thing you want is a responder accidentally (or a compromised account intentionally) viewing sensitive PII in an S3 bucket. SecurityAudit strips away data-plane access while keeping the control-plane visible.
Built-in compliance: Perfect for PCI-DSS, ISO 27001, CIS Benchmarks, or SOC 2 audits. Auditors love it because it’s auditable and least-privileged by design.
Audit logs & Evidence: It’s about understanding what happened and why. SecurityAudit gives you Security group configurations, Logging status, Policy structures, and timeline reconstruction. This is why it's the core of root cause analysis and forensic investigation.
Lightning-fast visibility: One role = instant access to the full security picture. No hunting for individual permissions or waiting for admin approvals.

Use Cases That Save the Day

Breach Investigation: Attacker in your environment? Your IR team immediately runs iam:GetAccountAuthorizationDetails and cloudtrail:LookupEvents to see exactly which roles were compromised and what they touched—without touching anything themselves.
Misconfiguration Triage: GuardDuty screams about suspicious S3 access? The team checks bucket policies, ACLs, and public access blocks in seconds, then cross-references with Security Hub and Config for context.
Insider Threat or Credential Abuse: Suspect a compromised access key? Pull IAM user policies, last-used timestamps, and Access Analyzer findings instantly.
Third-Party or MSSP Collaboration: Give external responders temporary assume-role access to the SecurityAudit & no need to grant them broader permissions.

Final Thoughts

Make the SecurityAudit IAM role a core part of your AWS incident response playbook. In a world where attackers move at cloud speed, ensuring your team can see everything without touching anything is no longer optional; it’s a competitive advantage in cybersecurity resilience. Your incident response team deserves the clearest possible view during chaos. SecurityAudit gives them exactly that and your team will thank you during the next breach hunt.

AWS Incident Response: ReadOnly vs ViewOnly access

Anwar — Sun, 22 Mar 2026 20:57:13 +0000

TL;DR:

ViewOnlyAccess: You can see the infrastructure (settings/tags) but not the data (files/records). It is useful for high-level visibility.

ReadOnlyAccess: You can see the infrastructure and the data, which is essential for deep investigation, forensic analysis and evidence. It also supports CLI-driven IR which wins hands-down on usability and speed.

Imagine you are the Lead Incident Responder for a fintech company. At 2:00 AM, your GuardDuty alerts scream: An unauthorized IP address is listing objects in your "Customer-Tax-Records" S3 bucket.

The "ViewOnly" Fail

Your junior analyst logs in with ViewOnlyAccess. They can see the bucket exists. They see the encryption is turned on (AES-256). They see the bucket policy.

The Problem: They try to check if the sensitive PDF files inside the bucket have been modified or if a Canary file has been tripped.
The Result: Access Denied. Because they only have View permissions, they can't see the content of the bucket. They are essentially a detective standing outside a house with a thermal camera; they know people are inside, but they can't see what they’re doing with the jewelry.

The "ReadOnly" Save

You quickly swap to a ReadOnlyAccess role.

The Action: You can now see the individual objects. You notice a 5GB .zip file created 10 minutes ago that shouldn't be there.
The Forensic Win: Because you have s3:GetObject, you can pull the metadata of that specific zip file to see the Last Modified timestamp and the IAM User/Role that created it. You realize the attacker didn't just look at the data they staged it for exfiltration.

1. The Core Differences

AWS ViewOnlyAccess

Think of this as Look but don't touch (and don't look at the data).
This policy allows a user to see the list of resources and their configurations (metadata) but explicitly denies access to the actual data stored within those resources.

Can do: See that an S3 bucket exists, see its tags, and see its encryption settings.

Cannot do: Read the objects inside the S3 bucket or look at the contents of a DynamoDB table.

AWS ReadOnlyAccess

Think of this as Look at everything, including the data.
This is a much broader permission set. It allows the user to see the metadata and read the underlying data.

Can do: List the S3 bucket and download the files inside it to check for malware or unauthorized data.

Cannot do: Delete, create, or modify resources.

2. CLI: Command-driven investigation support

When using the AWS CLI for Incident Response or audits, the difference between ReadOnlyAccess and ViewOnlyAccess becomes very practical.

CLI Command	ViewOnlyAccess	ReadOnlyAccess	Why It Matters
`aws s3api get-object`	❌	✔️	ViewOnly cannot download or read actual file content (bytes)
`aws cloudtrail lookup-events`	❌	✔️	ViewOnly can see the trail exists but cannot read log data

3. Which is needed for Incident Response?

For a primary Incident Responder, you almost always need ReadOnlyAccess.

Why?

Evidence Collection: To determine if data was exfiltrated or tampered with, you need to see the data itself. If you suspect a database has been injected with malicious code, ViewOnlyAccess won't let you see the records to confirm it.
Log Analysis: Some logs or specialized configurations are treated as data. An investigator needs to be able to pull these without being blocked by ViewOnlyAccess restrictions.
Root Cause Analysis: To understand the impact of a breach, you have to see what was accessed.

4. The Catch

In a real-world IR scenario, even ReadOnlyAccess might not be enough. You may need specific SecurityAudit permissions to create EBS Snapshots (which requires a Write action to create the snapshot), so you can move a disk image to a sandbox for forensics without touching the live production environment.

I would love to hear your thoughts. Let me know in the comments. Thanks

C4 Model real world example with Google Maps

Anwar — Tue, 18 Feb 2025 14:00:00 +0000

To illustrate C4 with a real world example, let's break down Google Maps as a case study and show how the same principles can apply to other applications.

Bonus

Mermaid Live (not sponsored 😊) is a powerful tool that enables developers and architects to create C4 model diagrams in a simple, text-based format and can automatically generate Context, Container, Component, and Code-level diagrams without needing complex drawing tools. I love Mermaid and have used it extensively to generate below images.

and for an interesting overview, to understand fundamentals and beyond please visit C4 Model

1. Context Diagram (C1):

Purpose : Who uses the system and why?
At the highest level, Google Maps interacts with its users and external systems like location services and traffic data providers.

Explanation:

Users interact with Google Maps via a web app or mobile app.
Google Maps integrates with external systems to provide location, traffic, and weather data.

2. Container Diagram (C2):

Purpose: Details the major pieces of the system: "What are the main applications or services?"
This level breaks Google Maps into its main containers, such as frontend, backend services, and databases.

Explanation:

Frontend: The interface where users interact.
API Gateway: Processes requests and routes them to the appropriate services.
Map Rendering Service: Retrieves and serves map tiles.
Routing Service: Calculates the best routes.
Traffic Service: Analyzes real-time traffic data.

3. Component Diagram (C3):

Purpose: Focuses on the internals of a container: "What modules exist in this service?"
At this level, we zoom into the Routing Service to see how it handles route calculations.

Explanation:

Route Planner: Orchestrates the selected and dynamic route calculations.
Traffic Adjuster: Modifies routes based on real-time traffic.
Distance Calculator: Computes distances between locations

4. Code Diagram (C4):

Purpose: At the code level, we describe the logic of a single component, such as the Distance Calculator. It can be a squence, workflow or any standard UML diagram.

Explanation:

calculate: Public method to calculate distances.
haversineFormula: Private method for geographical distance calculation.
adjustForTerrain: Adjusts distance based on terrain type.

Conclusion

The C4 model is more than just a set of diagrams; it's a framework for understanding and communicating complex software architectures. Its role in software development cannot be overstated.

C4 is ideal for bridging communication between technical and non-technical teams, providing clarity on both the big picture and the nitty-gritty. It's widely used for system documentation, architecture design, and onboarding teams.

Reference

C4 Model

Anwar — Tue, 18 Feb 2025 13:55:00 +0000

Ever been in a design meeting where someone draws a high-level architecture on a whiteboard, and by the end, it looks more like an ancient treasure map than a system diagram? 🤯 One person draws boxes labeled "Microservices" and "DB", while another sketches some arrows that somehow represent real-time, async, and batch processing all at once.

Then, a product manager walks in and asks, "But where is the business logic?"

— and that’s when the architect decides it's time for coffee. ☕

Software design often turns into a guessing game where different stakeholders see the system from different angles—developers worry about implementation, architects think in patterns, product managers want business clarity, and clients just want to know, "Will this work?" 🤔

This is where the C4 Model saves the day! 🦸‍♂️

1️⃣ What is the C4 Model?

The C4 Model is a set of hierarchical diagrams (Context, Container, Component, Code) and provides a structured way to visualize and describe software architecture. It helps to bridge the communication gap between technical and non-technical teams, providing clarity on both the big picture and the nitty-gritty. It's widely used for system documentation, architecture design and to analyze dependencies, internal and external integrations.

2️⃣ Breaking it Down: The Four C’s

✅ Context Diagram – The "Big Picture"

What does the system do?, Who uses the system and why?
High-level overview of the system and its interactions with users and external systems.
Audience: Business, Architect, Product, Developer

Example (Google Maps Context)

Users:

End users (regular users using the mobile or web app)

Businesses using Google Maps API for location services

Delivery services (Uber Eats, DoorDash) integrating Maps

External Systems:

Google Search (for place lookups)

Google Places API (for location-based business details)

Google Cloud (for data storage, compute services)

Payment services (Google Pay for ride-hailing, parking, toll payments)

✅ Container Diagram – The high-level building blocks

What are the main applications or services?
Helps us see how the system is set up and how it works with other integrations (Web App, Mobile App, DBs, Cache, Cloud, etc.)
Audience: Architect, Product, Developer

Example (Google Maps Containers)

Frontend (Mobile/Web Apps)

Google Maps Mobile App (Android/iOS)

Google Maps Web Application

Backend Services

Maps Data Service (stores roads, buildings, locations)

Routing Service (handles navigation, traffic updates)

Geolocation Service (converts latitude/longitude to addresses)

Street View Service (provides street-level images)

Google Places API (fetches restaurant, hotel, gas station data)

Traffic Analysis Service (integrates real-time traffic, historical trends)

Storage & Infrastructure

Google Cloud Storage (for map tile data, cached locations)

BigQuery (to process location-based data)

Firebase (syncs real-time data for mobile apps)

✅ Component Diagram – The internals of a container

What components/modules exist in application / service?
Overview of specific parts doing specialized jobs
Audience: Architect, Developer

Example (Google Maps Routing Service)

Route Calculation Module: Finds shortest path using algorithms like Dijkstra’s/A*.

Traffic Predictor: Uses historical + real-time data to estimate delays.

Alternative Route Finder: Suggests different routes.

User Location Service: Tracks real-time movement.

Third-Party Data Integrator: Fetches public transit, ride-hailing data (Uber, Lyft).

✅ Code Diagram – Zooming in on implementation details

At the code level, we describe the logic of a single component
Audience: Developer, Designer

Example (Google Maps Routing Code)

RouteController.java (exposes REST API)

RouteService.java (business logic for computing routes)

TrafficAnalysisService.java (predicts delays)

GraphProcessor.java (Dijkstra’s algorithm implementation)

GoogleMapsDB (stores precomputed routes for performance)

Each level helps different people get the information they need—without unnecessary complexity.

3️⃣Audience Perspectives: How Different Stakeholders See the C4 Model

💰 Clients/Business Owners: "As long as it doesn’t crash, Add values to customer and 💵 /💲I’m happy :)"
📈 Product Managers: "So this is how our product actually works?!"
🏗️ Architects: "Finally, a structured way to describe systems across teams!"
👨‍💻 Developers/Designers: "Ah, now I know which service calls what and where my code/design fits!"

4️⃣Why C4 Model is Better Than Chaos

No more ambiguous arrows.
No more lost in UML nightmares.
Consistent design across suites of products and teams.
Common nomenclature for technical and non-technical audience.

5️⃣Real-World Example: C4 Model in Action

Please review a short case study of architecture diagram using C4 and Google Maps.

6️⃣Best Practices for Using the C4 Model

Works across any language, framework, or platform, making it universally applicable.
Maintain consistency across teams.
Simplifies Complex Systems.
Supports Agile Development.
Facilitates Onboarding
Adjust details based on the audience.

Final Thoughts

Next time someone asks you to "just sketch the architecture real quick," resist the urge to draw random boxes and arrows. Instead, use the C4 Model to keep things clear, structured, and (most importantly) understandable!

What do you think? Would you like me to expand on any section? 😊. Let me know in comments. Thanks

References

A huge thanks to the online documentation, contributors, community and all the resources available that made this write-up possible.

SQL PATTERNS : Pivot and Unpivot in SQL - Transforming Data Effectively

Anwar — Tue, 18 Feb 2025 05:00:00 +0000

📌 Introduction

Handling data transformations is a crucial skill in SQL, especially for reporting and analytics. PIVOT and UNPIVOT operations help in restructuring data efficiently:

🔹 PIVOT: Converts row-based data into a column-based format.
🔹 UNPIVOT: Converts column-based data into row-based format.

In this article, we will explore both operations with real-world examples.

🛠 Understanding PIVOT in SQL

Scenario: You have sales data in a normalized format where each row represents sales for a specific month. You want to convert this into a columnar format to generate reports.

📌 Example: PIVOT Sales Data by Month

📊 Sample Table: Sales

Product	Month	Sales
Laptop	Jan	5000
Laptop	Feb	7000
Laptop	Mar	8000
Phone	Jan	3000
Phone	Feb	4500
Phone	Mar	5000

🔍 PIVOT Query

SELECT * 
FROM (
    SELECT Product, Month, Sales
    FROM Sales
) AS SourceTable
PIVOT (
    SUM(Sales) 
    FOR Month IN ([Jan], [Feb], [Mar])
) AS PivotTable;

✅ Output

Product	Jan	Feb	Mar
Laptop	5000	7000	8000
Phone	3000	4500	5000

🧐 Explanation

We used SUM(Sales) to aggregate values.
The FOR Month IN ([Jan], [Feb], [Mar]) clause dynamically transforms row values into column headers.

🔄 Understanding UNPIVOT in SQL

Scenario: You receive a dataset where sales are already pivoted by months, but you need to transform it back into a normalized row-based format.

📌 Example: UNPIVOT Sales Data

📊 Pivoted Table: Sales_Pivoted

Product	Jan	Feb	Mar
Laptop	5000	7000	8000
Phone	3000	4500	5000

🔍 UNPIVOT Query

SELECT Product, Month, Sales
FROM (
    SELECT Product, Jan, Feb, Mar
    FROM Sales_Pivoted
) AS PivotTable
UNPIVOT (
    Sales FOR Month IN (Jan, Feb, Mar)
) AS UnpivotTable;

✅ Output

Product	Month	Sales
Laptop	Jan	5000
Laptop	Feb	7000
Laptop	Mar	8000
Phone	Jan	3000
Phone	Feb	4500
Phone	Mar	5000

🧐 Explanation

The UNPIVOT operator converts multiple column values (Jan, Feb, Mar) back into row values under the Month column.
This makes it easier to analyze or join with other normalized tables.

📌 When to Use PIVOT and UNPIVOT?

Use Case	Operation
Convert rows into columns (e.g., monthly reports)	PIVOT
Convert columns into rows (e.g., normalizing data)	UNPIVOT

🚀 Conclusion

PIVOT and UNPIVOT are powerful SQL techniques that help in data transformation for better reporting and analysis. Mastering them will enable you to handle structured data more effectively.

💡 What are your thoughts?

Have you used PIVOT and UNPIVOT in your SQL queries? Let’s discuss in the comments! ⬇️

High Availability Mathematics for Mission-Critical Systems

Anwar — Tue, 21 Jan 2025 05:00:00 +0000

High availability is a critical metric that determines the reliability of a system or service. Often expressed as percentages, terms like "five nines" (99.999%) and "four nines" (99.99%) are used to describe uptime guarantees, typically in year. But what do these numbers mean, and how can they be achieved? Let’s explore.

Availability	Downtime (Yearly)	Systems Needed	Trade-offs
99.0%	87.6 hours i.e. 3 days 15 hours 39 minutes	Basic setup, single region, minimal redundancy	Low cost, high risk of downtime, minimal complexity
99.9%	8.76 hours	Single region, load balancers, backup, monitoring, scaling	Moderate cost and complexity
99.99%	52.6 minutes	Multi-AZ/Region, cross-region replication, real-time monitoring	Higher cost, more complexity, slight latency
99.999%	5.26 minutes	Global multi-region, advanced replication, zero downtime deployment	High cost, complex management, some latency
99.9999%	31.5 seconds	Multi-cloud, federated load balancing, AI-driven monitoring	Extremely high cost, significant operational burden

Difference Between Uptime and Availability?

Uptime and availability are both critical concepts when discussing system reliability, but they are distinct and used in slightly different contexts.

Uptime is about the time the system is actually running, and is often expressed as a percentage of total time

$U pt im e = (T o t a l U pT im e / T o t a lT im e) * 100$

Availability is a broader concept that includes uptime, measurement whether the system is operational and accessible and it also incorporates factors like system resilience, failover mechanisms, redundancy, and how quickly the system can recover from a failure and downtime during maintenance.

$Availability = (Total_UpTime / (Total_UpTime + Total_DownTime) ) * 100$

How to Calculate Uptime!

It’s the total time your system has been up and running. To find the availability percentage, divide the uptime by the total hours in the measured period and multiply by 100.

Here’s an example: Imagine a website that experienced 10 hours of downtime over the course of a year.

1️⃣ Total Hours in a Year: 8,760 hours
2️⃣ Downtime Experienced: 20 hours (Consider there are 4 quarterly product releases/maintenance upgrades that were deployed over the weekend and each took 5 hours to upgrade the PROD region)
3️⃣ Actual Uptime:

8760 total hours  - 20 downtime hours = 8,740 Uptime hours

4️⃣ Availability Percentage:

(8740 hours / 8760 hours) * 100 = 99.77168 %

Simplified View:

📅 Total Annual Hours: 8,760
🚫 Downtime: 20 hours
🆙 Operational Time: 8,740 hours
📈 Availability: 🎯 99.77%

This shows how a small amount of downtime, such as 20 hours in a year, can slightly lower the availability percentage, but still result in a highly reliable system.

Examples of Applications by Availability Level

99.00000% (Two Nines): Suitable for non-critical systems or internal tools where occasional downtime is acceptable.
99.90000% (Three and a Half Nines): Common for basic online services or small business websites.
99.99000% (Four Nines): Ideal for high-availability applications like e-commerce platforms or SaaS products.
99.99900% (Five Nines): Essential for mission-critical systems like banking, healthcare, or telecom.
99.99990% and Above: Ultra-high availability, often required for safety-critical systems (e.g., aviation control).

Final Thoughts!

Both 99.999% and 99.99% availability represent high reliability standards, but the choice depends on the criticality of your service and budget constraints. While achieving five nines may be essential for mission-critical systems, four nines may suffice for most business applications. The key is to balance cost, complexity, and user expectations while implementing robust strategies to minimize downtime.

What did I miss?

If you have suggestions/feedback worth mentioned here, please share them in the comment below. Consider liking and sharing if you find this helpful.
Thank you. Have a good day!

References

A huge thanks to the documentation, community and all the resources available that made this write-up possible.

SQL PATTERNS: ROW_NUMBER, RANK and DENSE_RANK

Anwar — Thu, 05 Dec 2024 02:37:29 +0000

Imagine you're tasked with building a ranking system for a gaming platform. How do you handle ties in scores? Take a look at the below image, where players on rank 3 have the same scores.

What if you want to identify and remove duplicate entries from a user database while keeping only the latest record? Or perhaps you need to paginate millions of rows in a web application efficiently.

This is where ROW_NUMBER, RANK, and DENSE_RANK step in as your go-to SQL window functions, turning daunting problems into manageable queries.

They assign ranks or numbers to rows within a result set. These functions are often paired with ORDER BY and PARTITION BY clauses.

ORDER BY defines how rows are ordered for ranking.

PARTITION BY divides rows into groups (optional). Ranking restarts for each group.

Ready to uncover how these SQL superheroes can transform your data operations? Let’s dive in!

Sample data

SELECT * FROM Employees;

ID	Department	EmployeeName	Salary
1	HR	Alice	9000
2	HR	Bob	8500
3	HR	Eve	8500
4	HR	Tom	8000
5	IT	Charlie	9500
6	IT	David	8900
7	IT	Emma	8900
8	IT	Frank	8700

Query Using ROW_NUMBER, RANK, and DENSE_RANK

Let's write a query to rank employees within each department based on their salaries in descending order

SELECT 
    Department,
    EmployeeName,
    Salary,
    ROW_NUMBER() 
      OVER (PARTITION BY Department ORDER BY Salary DESC) AS RowNum,
    RANK() 
     OVER (PARTITION BY Department ORDER BY Salary DESC) AS Rank,
    DENSE_RANK() 
     OVER (PARTITION BY Department ORDER BY Salary DESC) AS DenseRank
FROM Employees;

Department	EmployeeName	Salary	RowNum	Rank	DenseRank
HR	Alice	9000	1	1	1
HR	Bob	8500	2	2	2
HR	Eve	8500	3	2	2
HR	Tom	8000	4	4	3
IT	Charlie	9500	1	1	1
IT	David	8900	2	2	2
IT	Emma	8900	3	2	2
IT	Frank	8700	4	4	3

Key Differences

Function	Unique Sequence	Skips Ranks After Ties	Continuous Ranks
ROW_NUMBER	Yes	N/A	N/A
RANK	No	Yes	No
DENSE_RANK	No	No	Yes

Explanation

ROW_NUMBER generates a unique sequence for every row, ignoring ties.
RANK assigns the same rank for ties but skips the next ranks.
DENSE_RANK assigns the same rank for ties without skipping subsequent ranks.

Let me know if you’d like any other adjustments! 🚀

Summary

The versatility of ROW_NUMBER, RANK, and DENSE_RANK makes them indispensable for scenarios like pagination, deduplication, pattern analysis, prioritization, and much more. Let me know if you'd like more examples or further clarification on any of these use cases! 😊

Sample Script: Creating and Populating the Employees Table

Table Creation

CREATE TABLE Employees (
    EmployeeID INT PRIMARY KEY,
    Department VARCHAR(50),
    EmployeeName VARCHAR(50),
    Salary INT
);

Inserting Sample Data

INSERT INTO Employees (EmployeeID, Department, EmployeeName, Salary) VALUES
(1, 'HR', 'Alice', 9000),
(2, 'HR', 'Bob', 8500),
(3, 'HR', 'Eve', 8500),
(4, 'HR', 'Tom', 8000),
(5, 'IT', 'Charlie', 9500),
(6, 'IT', 'David', 8900),
(7, 'IT', 'Emma', 8900),
(8, 'IT', 'Frank', 8700);

References

Multithreading Concepts Part 3 : Deadlock

Anwar — Mon, 04 Nov 2024 12:12:34 +0000

Welcome to Part 3 of our multithreading series!

In Part 1, we explored Atomicity and Immutability.
In Part 2, we discussed Starvation.

In this part, we’ll dive into the mechanics of Deadlock in multithreading. What causes it, How to identify and preventive strategies you can use to avoid turning your code into a gridlocked intersection. Application grinds to a halt, often without any visible errors, leaving developers puzzled and systems frozen.

Navigating the Complex Tracks of Concurrency

A useful analogy to understand deadlock is to imagine a railway network with multiple trains on intersecting tracks.

Since each train is waiting for the next one to move, none can proceed, leading to a deadlock. In this scenario, the inefficient signaling system allowed each train to enter its respective section without first confirming that the next section would be free, trapping all trains in an unbreakable cycle.

This train example illustrates a typical deadlock in multithreading, where threads (like the trains) hold onto resources (track sections) while waiting for other resources to be freed, but none can progress. To prevent this kind of deadlock in software, effective resource management strategies—analogous to smarter railway signaling—must be implemented to avoid circular dependencies and ensure safe passage for each thread.

1. What is Deadlock?

Deadlock is a situation in which threads (or processes) are indefinitely blocked, waiting for resources that other threads hold. This scenario leads to an unbreakable cycle of dependencies, where no involved thread can make progress. Understanding the basics of deadlock is essential before exploring the methods for detection, prevention, and resolution.

2. Conditions for Deadlock

For a deadlock to occur, four conditions must be met simultaneously, known as the Coffman conditions:

Mutual Exclusion: At least one resource must be held in a non-shareable mode, meaning only one thread can use it at a time.
Hold and Wait: A thread must hold one resource and wait to acquire additional resources that other threads hold.
No Preemption: Resources cannot be forcibly taken away from threads. They must be released voluntarily.
Circular Wait: A closed chain of threads exists, where each thread holds at least one resource needed by the next thread in the chain.

Let's understand as a sequence diagram

In above animation,

Thread A holds Resource 1 and waits for Resource 2
While Thread B holds Resource 2 and waits for Resource 1

All four conditions shared above for deadlock are present, which results indefinite block. Breaking any one of them can prevent deadlock.

3. Detect / Monitor deadlock

Detecting deadlocks, especially in large-scale applications, can be challenging. However, the following approaches can help identify deadlocks

Tooling: Java's JConsole, VisualVM, and thread analyzers in IDEs can detect deadlocks in real-time.
Thread Dumps and Logs: Analyzing thread dumps can reveal waiting threads and the resources they’re holding.

For detailed overview to understand how to debug/monitor deadlocks please visit Debug and Monitor Deadlock using VisualVM and jstack

4. Strategies for Deadlock Prevention

Applying the Wait-Die and Wound-Wait Schemes
Wait-Die Scheme: When a thread requests a lock held by another thread, the database assesses the relative priority (usually based on the timestamp of each thread). If the requesting thread has a higher priority, it waits; otherwise, it dies (restarts).
Wound-Wait Scheme: If the requesting thread has a higher priority, it wounds (preempts) the lower-priority thread by forcing it to release the lock.
Immutable Objects for Shared State
Design shared state as immutable wherever possible. Since immutable objects cannot be modified, they require no locks for concurrent access, reducing the risk of deadlock and simplifying code.
Using tryLock with Timeout for Lock Acquisition: Unlike a standard synchronized block, ReentrantLock allows using tryLock(timeout, unit) to attempt acquiring a lock within a specified period. If the lock isn’t acquired within that time, it releases resources, preventing indefinite blocking.

ReentrantLock lock1 = new ReentrantLock();
ReentrantLock lock2 = new ReentrantLock();

public void acquireLocks() {
    try {
        if (lock1.tryLock(100, TimeUnit.MILLISECONDS)) {
            try {
                if (lock2.tryLock(100, TimeUnit.MILLISECONDS)) {
                    // Critical section
                }
            } finally {
                lock2.unlock();
            }
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    } finally {
        lock1.unlock();
    }
}

Lock Ordering and Releasing Set a strict, global order for lock acquisition. If all threads acquire locks in a consistent order, cyclic dependencies are less likely to form, thus avoiding deadlocks. For example, always acquire lock1 before lock2 throughout the codebase. This practice can be challenging in larger applications but is very effective in reducing deadlock risk.

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class LockOrderingExample {

    private static final Lock lock1 = new ReentrantLock();
    private static final Lock lock2 = new ReentrantLock();

    public static void main(String[] args) {
        Thread thread1 = new Thread(() -> {
            acquireLocksInOrder(lock1, lock2);
        });

        Thread thread2 = new Thread(() -> {
            acquireLocksInOrder(lock1, lock2);
        });

        thread1.start();
        thread2.start();
    }

    private static void acquireLocksInOrder(Lock firstLock, Lock secondLock) {
        try {
            firstLock.lock();
            System.out.println(Thread.currentThread().getName() + " acquired lock1");

            secondLock.lock();
            System.out.println(Thread.currentThread().getName() + " acquired lock2");

            // Perform some operations

        } finally {
            secondLock.unlock();
            System.out.println(Thread.currentThread().getName() + " released lock2");

            firstLock.unlock();
            System.out.println(Thread.currentThread().getName() + " released lock1");
        }
    }
}

Use Thread-Safe/Concurrent Collections: Java’s java.util.concurrent package provides thread-safe implementations of common data structures (ConcurrentHashMap, CopyOnWriteArrayList, etc.) that handle synchronization internally, reducing the need for explicit locks. These collections minimize deadlocks as they’re designed to avoid the need for explicit locking, using techniques like internal partitioning.
Avoid Nested Locks
Minimize acquiring multiple locks within the same block to avoid circular dependencies. If nested locks are necessary, use consistent lock ordering

Key Takeaways for Software Engineers

Whenever you create a design that requires locking, you open up the possibility for deadlocks.
Deadlock is a blocking issue caused by a cycle of dependencies between processes. No process can make progress because each one is waiting for a resource held by another, and none can proceed to release resources.
Deadlock is more severe, as it completely halts the involved processes and requires breaking the deadlock cycle for recovery.
Deadlock can occur only when there are two different locks, i.e. when you are holding a lock and waiting for another lock to release. (There are more conditions on deadlocks, however).
Thread-safety does not mean deadlock free. It only guarantees that the code will operate according to its interface, even when called from multiple threads. Making a class thread-safe usually includes adding locks to guarantee safe execution.

Outro

Whether you're a beginner or a seasoned developer, understanding deadlock is crucial for writing robust, efficient code in concurrent systems. In this article, we explored what deadlocks are, their causes, and practical ways to prevent them. By implementing effective resource allocation strategies, analyzing task dependencies, and utilizing tools like thread dumps and deadlock detection tools, developers can minimize deadlock risk and optimize their code for smooth concurrency.

As we continue our journey through the core concepts of multithreading, stay tuned for the next articles in this series. We’ll dive into Critical Sections, understanding how to manage shared resources safely among multiple thread. We will also discuss the concept of Race Conditions, a common concurrency issue that can lead to unpredictable behavior and bugs if left unchecked.

With each step, you’ll gain deeper insights into how to make your applications thread-safe, efficient, and resilient. Keep pushing the boundaries of your multithreading knowledge to build better, more performant software!

References

Debug and Monitor Java App with VisualVM and jstack

Anwar — Sun, 03 Nov 2024 22:45:20 +0000

Java applications, especially those running in production, can develop performance bottlenecks, deadlocks, and memory leaks that can be challenging to trace. When these issues arise, quick and effective debugging is essential to keep applications running smoothly and to maintain a positive user experience. This is where VisualVM and JStack become invaluable tools for Java developers.

VisualVM, with its powerful profiling and monitoring capabilities, and jstack, offering detailed thread dumps, are a dynamic duo that enables developers to detect, diagnose, and debug complex issues with ease.

Diagnosing and resolving deadlocks is critical, especially in high-performance applications. This guide will explore how to detect deadlocks and obtain thread dumps using two powerful Java tools: VisualVM and jstack.

1. Understanding Deadlocks and Thread Dumps

Before diving into the tools, let's clarify a few basics:

Deadlock: A situation where threads are waiting for each other to release resources, leading to an indefinite blocking cycle.

Thread Dump: A snapshot of the active threads within a Java application at a given time, including details on their states and any locks they are holding or waiting on. A thread dump is crucial in analyzing and identifying deadlock sources in Java applications, allowing developers to pinpoint the cause of blocked threads.

2. Introduction to VisualVM

VisualVM is a visual tool integrating several command-line JDK tools to deliver a comprehensive overview of Java applications. It’s widely used to monitor and profile applications, diagnose memory leaks, and analyze performance.

Key Features

Live monitoring and profiling
Thread analysis
Memory and CPU usage insights
Thread dumps for deadlock analysis

Debug using VisualVM (for Java applications)

Download VisualVM
Open VisualVM.
Connect to the running JVM process.
In the monitoring tools, you can click thread dump or view thread details in real time.

3. Introduction to jstack

jstack is an invaluable command-line tool for any Java developer dealing with complex applications that rely heavily on threads. By providing detailed insights into thread states, locking behavior, and execution flow, jstack simplifies the debugging process, making it easier to spot and resolve issues like deadlocks, performance bottlenecks, and application freezes.

Key Features

jstack shows the state of each thread, such as RUNNABLE, BLOCKED, WAITING, or TIMED_WAITING.
Capture stack traces for live or hung processes to help in debugging complex threading issues.
jstack marks deadlocked threads in the thread dump, allowing you to quickly identify them.
Obtain a thread dump, which lists all active threads in the JVM.
Paired with other tools like VisualVM or jmap, jstack can help trace memory leaks back to threads responsible for excessive object creation or holding onto references.
By analyzing thread dumps, developers can identify problematic synchronization, excessive blocking, or opportunities to reduce contention, leading to improved concurrency and responsiveness.

Using jstack to Obtain and Analyze Thread Dumps

To capture a thread dump of a running Java application using jstack, you’ll need the process ID (PID) of the Java process. Here’s a step-by-step guide:

Step 1: Find the Process ID (PID) of the Java Application

C:\Program Files\Java\jdk-21\bin>jps -l
12912
22480 org.springframework.ide.vscode.boot.app.BootLanguageServerBootApp
24020 jdk.jcmd/sun.tools.jps.Jps
14344 org/netbeans/Main
21944 deadlock/deadlock.DeadlockExample

Step 2: Use jstack to Capture the Thread Dump

C:\Program Files\Java\jdk-21\bin>jstack 21944
2024-11-02 11:12:18
Full thread dump Java HotSpot(TM) 64-Bit Server VM (21.0.5+9-LTS-239 mixed mode, sharing):

Threads class SMR info:
.
..
....
...

"Thread-0" #29 [18484] prio=5 os_prio=0 cpu=0.00ms elapsed=1896.34s tid=0x000001bb3395ac40 nid=18484 waiting for monitor entry  [0x00000099227ff000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at deadlock.DeadlockExample.lambda$0(deadlock/DeadlockExample.java:23)
        - waiting to lock <0x000000070d03c740> (a java.lang.Object)
        - locked <0x000000070d05a828> (a java.lang.Object)
        at deadlock.DeadlockExample$$Lambda/0x000001bb350019f8.run(deadlock/Unknown Source)
        at java.lang.Thread.runWith(java.base@21.0.5/Thread.java:1596)
        at java.lang.Thread.run(java.base@21.0.5/Thread.java:1583)

"Thread-1" #30 [23240] prio=5 os_prio=0 cpu=0.00ms elapsed=1896.34s tid=0x000001bb3395b2a0 nid=23240 waiting for monitor entry  [0x00000099228ff000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at deadlock.DeadlockExample.lambda$1(deadlock/DeadlockExample.java:41)
        - waiting to lock <0x000000070d05a828> (a java.lang.Object)
        - locked <0x000000070d03c740> (a java.lang.Object)
        at deadlock.DeadlockExample$$Lambda/0x000001bb35001c08.run(deadlock/Unknown Source)
        at java.lang.Thread.runWith(java.base@21.0.5/Thread.java:1596)
        at java.lang.Thread.run(java.base@21.0.5/Thread.java:1583)

...
.....
..
Found one Java-level deadlock:
=============================
"Thread-0":
  waiting to lock monitor 0x000001bb117727a0 (object 0x000000070d03c740, a java.lang.Object),
  which is held by "Thread-1"

"Thread-1":
  waiting to lock monitor 0x000001bb11772500 (object 0x000000070d05a828, a java.lang.Object),
  which is held by "Thread-0"

Java stack information for the threads listed above:
===================================================
"Thread-0":
        at deadlock.DeadlockExample.lambda$0(deadlock/DeadlockExample.java:23)
        - waiting to lock <0x000000070d03c740> (a java.lang.Object)
        - locked <0x000000070d05a828> (a java.lang.Object)
        at deadlock.DeadlockExample$$Lambda/0x000001bb350019f8.run(deadlock/Unknown Source)
        at java.lang.Thread.runWith(java.base@21.0.5/Thread.java:1596)
        at java.lang.Thread.run(java.base@21.0.5/Thread.java:1583)
"Thread-1":
        at deadlock.DeadlockExample.lambda$1(deadlock/DeadlockExample.java:41)
        - waiting to lock <0x000000070d05a828> (a java.lang.Object)
        - locked <0x000000070d03c740> (a java.lang.Object)
        at deadlock.DeadlockExample$$Lambda/0x000001bb35001c08.run(deadlock/Unknown Source)
        at java.lang.Thread.runWith(java.base@21.0.5/Thread.java:1596)
        at java.lang.Thread.run(java.base@21.0.5/Thread.java:1583)

Found 1 deadlock.

Note

jstack is available in the JDK, so ensure that the JDK is installed and accessible in your environment.
Using jstack on some systems may require administrator privileges.
Using jstack -l 12345 > threaddump.txt saves the thread dump to a file called threaddump.txt.

Outro

VisualVM and jstack are two essential tools in the Java developer’s toolkit for diagnosing and troubleshooting Java applications, particularly when dealing with performance issues, deadlocks, and thread bottlenecks.

Together, VisualVM and jstack offer a comprehensive approach to debugging Java applications, with VisualVM providing broad, real-time performance insights and jstack enabling deep thread-level analysis. Their combined usage allows developers to effectively diagnose and resolve complex Java issues in both development and production environments.

Reference

A huge thanks to the online documentation, community and all the resources available that made this write-up possible.

Multithreading Concepts Part 2 : Starvation

Anwar — Mon, 21 Oct 2024 17:11:48 +0000

Welcome to Part 2 of our multithreading series!
In this part, we’ll dive deeper to understand starvation as it is essential for engineers, because it ensures fairness and system performance. By recognizing starvation risks, engineers can design systems that prioritize fairness, prevent resource monopolization, and ensure all threads get the necessary CPU time and resources to function optimally.

The Never-Ending Wait in Game Lobbies

Imagine you’re playing an online multiplayer game, and you’re trying to join a lobby for a popular game mode, like a team battle. You’ve been waiting in the lobby for a while, but every time a match starts, a new batch of players with faster internet or higher skill ranking gets prioritized and added to the game before you. You see matches starting over and over, but you never seem to get in!

You are technically in the queue, but because other players with faster response times or higher ranks keep getting into games first, you are left in the lobby indefinitely. Despite having a perfectly functional system, you’re denied the chance to play because of how the matchmaking algorithm unfairly prioritizes others.

1. Starvation

Starvation is a situation in which a process is continuously denied access to the resources it needs to proceed, even though those resources are available. The process remains in a waiting state because higher-priority processes or other resource allocation policies prevent it from acquiring the necessary resources. Unlike deadlock, the resources are not entirely unavailable, but the process is unable to access them due to unfair scheduling.

2. Causes

Priority Inversion: When a higher-priority process is waiting for a resource held by a lower-priority process, the lower-priority process may be starved of CPU time if other higher-priority processes keep arriving.
Resource Allocation Policies: Some scheduling algorithms may favor certain processes (usually those with higher priorities), leading to a situation where lower-priority processes are rarely allocated resources.
Poorly Designed Algorithms: If the resource allocation algorithm is not balanced or fair, it may lead to certain processes being continuously overlooked.
High Resource Demand: If a few processes demand an excessive amount of resources, they can starve other processes by monopolizing those resources.
Long Wait Times: Processes that are frequently preempted or that find themselves in competition for limited resources may experience starvation.

3. Preventing Starvation

Using ReentrantLock with Fairness

Java’s ReentrantLock provides an option to enforce fairness. By using the ReentrantLock constructor with the true argument, we can ensure that threads acquire the lock in a first-come, first-served (FCFS) manner, preventing starvation.

private final Lock lock = new ReentrantLock(true); // Fair lock

Using Semaphore for Fair Resource Sharing

A Semaphore is used to control access to a limited number of resources. By using a semaphore with fairness enabled, we can ensure that threads acquire permits in a fair order, avoiding starvation.

private final Semaphore sp = new Semaphore(1, true); // Fair semaphore

The Semaphore(1, true) is a semaphore with only one permit and fairness enabled.

Avoiding Starvation in Producer-Consumer Problem (Using BlockingQueue)

In traditional producer-consumer problems, starvation may occur if the producer overwhelms the consumer or if consumers are denied access to the shared resource. BlockingQueue prevents this because it automatically handles synchronization between producers and consumers. Both the producer and consumer are blocked when the queue is full or empty, respectively. This ensures a fair balance between the two and prevents one from overwhelming the other, thus avoiding starvation.

Using Java’s ForkJoinPool for Fair Task Scheduling

In scenarios where multiple tasks are forked and joined, ForkJoinPool in Java provides a way to balance the work fairly among threads. It ensures work-stealing, preventing starvation of less active threads. Java’s ForkJoinPool efficiently handles task splitting and balancing, ensuring that no thread starves for work. This is achieved using a work-stealing algorithm, where idle threads steal tasks from busy threads to keep everything moving smoothly

4. How Operating System prevents Starvation

Operating systems (OS) use various techniques to avoid starvation—a situation where certain processes or threads are denied necessary resources (such as CPU time, memory, or I/O access) for prolonged periods because higher-priority tasks dominate. Here are some of the common ways an OS prevents starvation:

No.	Method	Description	Prevents Starvation By
1	Aging	Gradually increases priority of waiting processes.	Prevents long waits by adjusting priority based on wait time.
2	Round-Robin Scheduling	Allocates CPU time in a fixed cyclic order.	Ensures all processes get CPU time, avoiding starvation.
3	Completely Fair Scheduler	Allocates CPU based on fairness, independent of priority.	Ensures fair distribution of CPU time.
4	Priority Boosting	Temporarily raises the priority of starved processes holding important resources.	Prevents priority inversion and ensures high-priority tasks get needed resources.
5	Multilevel Feedback Queues	Dynamically adjusts process priorities based on behavior.	Promotes long-waiting processes to higher-priority queues.
6	Semaphores with Fairness	Ensures fair access to resources through FIFO queues.	Prevents low-priority tasks from being perpetually blocked by higher-priority tasks.
7	Fair Resource Allocation	Distributes system resources like CPU and memory based on process demand and need.	Prevents resource-hogging processes from starving others.
8	Fair I/O Scheduling	Prioritizes I/O requests to ensure timely completion for all processes.	Prevents disk I/O starvation for processes making low-priority requests.

By implementing these strategies, operating systems can ensure that no process or thread is indefinitely starved for resources, promoting a more fair and efficient use of system resources.

Key Takeaways for Software Engineers

Starvation is a progress issue where a process keeps being denied access to a resource, but doesn’t necessarily involve other processes blocking it in a deadlock cycle. It is often caused by unfair scheduling or resource allocation.
Starvation happens even though the resource it needs is available, but it never gets the chance to acquire it.
Starvation also happens even when there is no deadlock on the system.
Starvation can be a side effect of deadlock prevention (e.g., prioritizing certain processes to avoid deadlock), so it’s crucial to balance fairness with deadlock avoidance strategies.

Reference

A huge thanks to the online documentation, community and all the resources available that made this write-up possible.

Multithreading Concepts Part 1: Atomicity and Immutability

Anwar — Mon, 30 Sep 2024 01:39:30 +0000

Understanding key multithreading concepts is crucial for software developers, as it not only enhances skill set but also directly impacts application development, scalability, and the overall quality of software solutions.

Atomicity

In the context of multithreading, atomic operations ensure that a thread can execute a series of actions without interruption from other threads. Multiple threads may attempt to read or write shared data simultaneously. Without atomicity, concurrent modifications can lead to inconsistent or unexpected results, commonly known as race conditions.

Java Specification guarantees that 'reading' and 'writing' are atomic operations not their combinations. so an operation which 'reads, adds 1 and then writes the result back' is not atomic as per specification. such operations are called compound operations and they usually need to be atomic in context of their usage in our code.

Examples of Atomic Operations:

Incrementing a counter: If two threads increment a counter at the same time without atomicity, they may both read the same value and write back the same incremented value, leading to a loss of one increment.
Updating a shared variable: If one thread is reading a value while another is modifying it, without atomicity, the reading thread may get an inconsistent value.

Achieving Atomicity:

Atomic Classes: Many programming languages provide atomic classes (e.g., AtomicIntegerin Java) that encapsulate operations that are guaranteed to be atomic.
Synchronized Methods/Blocks: In languages like Java, you can use the synchronized keyword to ensure that only one thread can execute a block of code or a method at a time.
Locks: Using explicit locks (e.g., ReentrantLockin Java) to manage access to shared resources.

Benefits

Performance: Classes in java.util.concurrent.atomic also provide a lock-free approach to ensure thread safety, making them a preferred choice in many scenarios.
Simplicity: Using atomic classes simplifies code, as developers don’t need to manage locks and can focus on the logic of the program.
Thread Safety: Atomic operations ensure that variables are safely updated across multiple threads without the risk of data corruption or race conditions.

Immutability

Immutability refers to the property of an object whose state cannot be modified after it is created. In programming, immutable objects are those that, once initialized, cannot be changed or altered. Instead of modifying an immutable object, a new object is created with the desired changes.

Immutable means that once the constructor for an object has completed execution that instance can't be altered.

Characteristics of Immutable Objects

No State Change: Once an immutable object is created, its state (attributes or fields) remains constant throughout its lifetime.
Thread-Safe: Immutable objects can be safely shared between multiple threads without the need for synchronization, as they cannot be modified.
Hashcode Stability: The hashcode of an immutable object remains the same throughout its lifetime, making it suitable for use in hash-based collections like HashMap or HashSet.

Achieving Immutability:

Use of Records (in Java 14+): In Java, the record feature provides a concise way to create immutable data classes.

public record ImmutablePoint(int x, int y) {}

Use Immutable Data Structures: Utilize existing immutable data structures provided by the programming language or libraries, such as:

Java: Collections.unmodifiableList(), List.of(), Set.of()
C#: ImmutableList, ImmutableArray from System.Collections.Immutable
Python: Tuplesare inherently immutable.

Use Final Fields: Declare the fields of a class as final. This ensures that the fields can only be assigned once, during object construction.
No Setters: Avoid providing setter methods for mutable fields. This prevents external code from changing the state of an object after it's been constructed.

public final class ImmutablePoint {
    private final int x;
    private final int y;

    public ImmutablePoint(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return x;
    }

    public int getY() {
        return y;
    }
}

Static Factory Methods: Instead of providing a public constructor, use static factory methods that return new instances of the object, making it clear that the state cannot be changed
Builder Pattern (for complex objects): For objects that require many parameters, use the builder pattern to create immutable objects. The builder accumulates the parameters and constructs an immutable instance at the end.

Benefits

Concurrency: If the internal structure of an immutable object is valid, it will always be valid. There's no chance that different threads can create an invalid state within that object. Hence, immutable objects are Thread Safe.
Garbage collection: It's much easier for the garbage collector to make logical decisions about immutable objects.

Outro

Arming yourself with this knowledge not only enhances your ability to write high-performance code but also prepares you for the challenges of modern software development, where responsiveness and scalability are paramount. As you continue your journey into the world of multithreading, remember that each concept you master will contribute to your growth as a developer and your capacity to create applications that meet and exceed user expectations.

Stay tuned as we will focus on starvation, deadlock, race-condition, OS scheduling and much more in upcoming write-up, that would elevate your programming skills and boost your career!

References

A huge thanks to the online documentation, community and all the resources available that made this write-up possible.