What Is Resource Management - Learning Module

Loading content...

0/246

Types of Resources: Memory, Files, Connections, Handles

A Taxonomy of System Resources

Resources come in many forms, each with unique characteristics, management requirements, and failure modes. While the previous page established the abstract definition of resources, this page provides a concrete taxonomy—a comprehensive catalog of the resource types you'll encounter as a professional software engineer.

Understanding these categories is not merely academic. Each resource type has:

Specific acquisition mechanisms — How you obtain it
Characteristic limits — What constrains availability
Preferred management patterns — How to handle it safely
Distinct failure modes — What goes wrong when mismanaged

Let's systematically explore each major category.

What You Will Learn

By the end of this page, you will understand: (1) The four major categories of system resources, (2) The specific characteristics of memory, file, connection, and handle resources, (3) The management requirements for each type, and (4) How to recognize which category a resource belongs to.

Memory Resources

Memory is the most fundamental resource in computing. Every object, every data structure, every buffer consumes memory. While managed languages with garbage collection abstract away much of memory management, memory resources still require attention in several contexts.

Categories of memory resources:

1. Heap Memory (Managed)

In languages like Java, C#, Python, and JavaScript, heap memory is managed by the garbage collector. Objects are allocated on the heap and automatically reclaimed when no longer referenced. This appears automatic, but:

Large objects can still exhaust available heap
Memory pressure triggers GC pauses that affect latency
In-memory caches grow unbounded without explicit eviction
Object pools must be sized appropriately

memory-considerations.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Memory resource considerations in managed languages
 
// ❌ Unbounded cache - memory will grow indefinitely
const userCache = new Map<string, User>();
 
function getUser(id: string): User {
    if (!userCache.has(id)) {
        const user = loadFromDatabase(id);
        userCache.set(id, user);  // Never evicted!
    }
    return userCache.get(id)!;
}
 
// ✅ Bounded cache with LRU eviction
import { LRUCache } from 'lru-cache';
 
const boundedCache = new LRUCache<string, User>({
    max: 10000,                    // Maximum entries
    maxSize: 50 * 1024 * 1024,     // Maximum 50MB
    sizeCalculation: (user) => JSON.stringify(user).length,
    ttl: 1000 * 60 * 60,           // 1 hour TTL
});
 
// Memory is now bounded and automatically managed

2. Native/Unmanaged Memory

Some languages allow direct allocation of memory outside the managed heap:

C/C++: malloc(), new, stack allocations
Rust: Ownership system with explicit lifetimes
Managed languages with native interop: Node.js Buffer.allocUnsafe(), Java ByteBuffer.allocateDirect(), C# unmanaged memory

Native memory bypasses garbage collection entirely. You must explicitly allocate and deallocate, or use patterns like RAII (Resource Acquisition Is Initialization) that tie memory lifetime to object scope.

native-memory.cpp
C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Native memory management in C++
 
// ❌ Manual allocation - easy to leak
void risky() {
    int* data = new int[1000];
    
    if (someCondition()) {
        return;  // Memory leaked! Never deleted.
    }
    
    delete[] data;  // Only reached if condition is false
}
 
// ✅ RAII with smart pointers - cannot leak
#include <memory>
 
void safe() {
    auto data = std::make_unique<int[]>(1000);
    
    if (someCondition()) {
        return;  // data automatically deleted
    }
    
    // data automatically deleted here too
}
 
// ✅ RAII with standard containers
void safest() {
    std::vector<int> data(1000);
    // Memory managed automatically by vector
    // Cannot leak under any circumstances
}

3. Shared Memory

Shared memory regions allow multiple processes to access the same memory space:

Created via OS APIs (shmget, mmap with MAP_SHARED)
Must be explicitly created, attached, detached, and destroyed
Requires synchronization between processes
Common in high-performance IPC scenarios

4. Memory-Mapped Files

Memory-mapped files map file contents directly into process address space:

Created via mmap() (Unix) or CreateFileMapping() (Windows)
Combine aspects of memory and file resources
Must be explicitly unmapped when done
Can outlive process if not cleaned up (depending on backing)

Memory Resource Failure Modes

•Out of Memory (OOM) — Heap exhaustion crashes the process or triggers OS OOM killer
•Memory Fragmentation — Available memory exists but not in usable contiguous blocks
•GC Pressure — Excessive allocation triggers frequent, long GC pauses
•Memory Leaks — Unreachable memory (native) or references held too long (managed)
•Virtual Memory Exhaustion — Address space (32-bit) or page table limits exceeded

File Resources

Files represent persistent data storage, one of the oldest and most fundamental resource types in computing. Despite their ubiquity, file resources are frequently mismanaged, causing data corruption, resource leaks, and cross-process conflicts.

The anatomy of a file resource:

When you 'open a file,' multiple resources are actually involved:

File descriptor/handle — An OS-level reference to the open file
File position pointer — Current read/write position within the file
Lock state — Shared or exclusive locks held on the file
Buffer state — In-memory buffers for read/write operations
Metadata access — Cached inode information, timestamps, permissions

Each of these has lifecycle implications. Failing to close a file doesn't just leak a number—it leaves buffers unflushed, locks held, and kernel resources consumed.

File Opening Modes and Implications
Mode	Description	Resource Implications
Read-only	Open for reading	Shared access, no write conflicts
Write-only	Open for writing	May truncate, exclusive write access
Read-write	Open for both	Combines both access patterns
Append	Write only at end	Seeking for write disabled
Exclusive create	Fail if exists	Atomic creation for uniqueness
Truncate	Clear on open	Existing content lost immediately

File descriptor limits:

Operating systems impose strict limits on file descriptors:

Per-process limit: Often 1024 (soft) to 65535 (hard) on Linux
System-wide limit: Total open files across all processes

Exceeding these limits causes EMFILE ('Too many open files') or ENFILE ('File table overflow') errors. These errors are particularly insidious because:

They appear suddenly when the limit is hit
They affect all file operations, including network sockets (which are also file descriptors)
They can cascade as error handling paths try to log to files

Special file types:

Not all 'files' are regular disk files:

Special File Resource Types

•Directories — Require different handling than regular files
•Symbolic links — Follow or not depending on open flags
•Named pipes (FIFOs) — Inter-process communication channels
•Unix domain sockets — File-based network endpoints
•Device files — /dev entries representing hardware
•Proc/sys files — Virtual files representing kernel state

file-resource-management.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import { open, FileHandle } from 'fs/promises';
 
// ❌ Leaky file handling
async function leakyRead(path: string): Promise<string> {
    const file = await open(path, 'r');
    const content = await file.readFile('utf-8');
    // file.close() never called - file descriptor leaked!
    return content;
}
 
// ❌ Leak on error path
async function leakyOnError(path: string): Promise<string> {
    const file = await open(path, 'r');
    const content = await file.readFile('utf-8');
    
    if (!content.startsWith('HEADER')) {
        throw new Error('Invalid format');
        // file.close() skipped due to throw!
    }
    
    await file.close();
    return content;
}
 
// ✅ Proper file resource management with try/finally
async function safeRead(path: string): Promise<string> {
    const file = await open(path, 'r');
    try {
        const content = await file.readFile('utf-8');
        if (!content.startsWith('HEADER')) {
            throw new Error('Invalid format');
        }
        return content;
    } finally {
        await file.close();  // Always executes
    }
}
 
// ✅ Modern approach: using helper that encapsulates cleanup
import { readFile } from 'fs/promises';
 
async function simplestRead(path: string): Promise<string> {
    // readFile opens, reads, and closes automatically
    return readFile(path, 'utf-8');
}

Connection Resources

Connections represent bidirectional communication channels between your application and external systems. They are among the most expensive resources to acquire and most impactful when mismanaged.

Network connections encompass multiple stacked resources:

Socket — The OS-level endpoint of network communication
TCP connection — Established via three-way handshake
TLS session — Encrypted layer with negotiated keys
Protocol session — HTTP/2 streams, database sessions, etc.
Authentication state — Logged-in credentials, tokens

Each layer adds establishment overhead and cleanup requirements.

The connection lifecycle:

┌─────────────────────────────────────────────────────────────┐
│                    CONNECTION LIFECYCLE                      │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  [Closed] ──Create──► [Connecting] ──Handshake──► [Open]   │
│                                                     │       │
│                                                     ▼       │
│  [Closed] ◄──Close── [Closing] ◄──Shutdown── [Active]      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Connections can also enter error states: connection refused, connection reset, timeout. Error handling must account for all states.

Common Connection Types and Their Costs
Connection Type	Establishment Cost	Typical Pool Size	Leak Impact
PostgreSQL	5-50ms	10-50	Query failures, 'too many clients'
MySQL	5-30ms	10-100	Connection refused errors
Redis	1-10ms	10-50	Slower than expected (creates on demand)
MongoDB	10-100ms	5-50	Timeout errors
HTTP/1.1	50-200ms (TLS)	Per-host limits	Socket exhaustion
HTTP/2	50-200ms (TLS)	Few, multiplexed	Stream limits hit
gRPC	50-200ms (TLS)	Few, multiplexed	Stream/message limits
WebSocket	50-200ms (TLS)	Application-dependent	Memory growth, client timeouts

Connection pooling:

Due to high establishment costs, connections are almost always pooled. A pool:

Maintains a set of pre-established connections
Lends connections to requesting code
Receives connections back when operations complete
Validates connections are still healthy
Automatically creates new connections when pool is empty (up to max)
Closes idle connections that exceed idle timeout

Connection pools transform connection usage from acquire-release to borrow-return semantics.

connection-pooling.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
import { Pool, PoolClient } from 'pg';
 
// Connection pool configuration
const pool = new Pool({
    host: 'localhost',
    database: 'myapp',
    user: 'app',
    password: process.env.DB_PASSWORD,
    
    // Pool sizing
    min: 5,              // Minimum connections to maintain
    max: 20,             // Maximum connections allowed
    
    // Timeouts
    idleTimeoutMillis: 30000,      // Close idle connections after 30s
    connectionTimeoutMillis: 5000,  // Fail if can't connect in 5s
    
    // Health checks
    allowExitOnIdle: true,          // Allow process to exit when idle
});
 
// ❌ Leaky: Connection borrowed but never returned
async function leakyQuery(id: string): Promise<User> {
    const client = await pool.connect();  // Borrow from pool
    const result = await client.query(
        'SELECT * FROM users WHERE id = $1',
        [id]
    );
    // client.release() never called!
    // Connection stuck - pool will exhaust at max size
    return result.rows[0];
}
 
// ❌ Leaky on error: Connection not returned if query fails
async function leakyOnError(id: string): Promise<User> {
    const client = await pool.connect();
    const result = await client.query(
        'SELECT * FROM users WHERE id = $1',
        [id]
    );
    // If query throws, release() is skipped
    client.release();
    return result.rows[0];
}
 
// ✅ Correct: Always return connection with try/finally
async function safeQuery(id: string): Promise<User> {
    const client = await pool.connect();
    try {
        const result = await client.query(
            'SELECT * FROM users WHERE id = $1',
            [id]
        );
        return result.rows[0];
    } finally {
        client.release();  // Always returns to pool
    }
}
 
// ✅ Even better: Use pool.query() for simple cases
async function simpleQuery(id: string): Promise<User> {
    // pool.query() automatically borrows, executes, and releases
    const result = await pool.query(
        'SELECT * FROM users WHERE id = $1',
        [id]
    );
    return result.rows[0];
}

Connection Leak Death Spiral

Connection leaks often trigger a death spiral: pool exhausts → requests wait for connections → timeouts occur → error handlers may leak too → failed requests retry → more load → faster exhaustion. Detection and prevention are critical.

Handle Resources

Handles are opaque references to kernel or system objects. Unlike connections (which represent channels) or memory (which represents storage), handles are tokens that grant capability. Possessing a valid handle entitles you to perform operations on the underlying resource.

Handle semantics:

Handles are typically integer values (file descriptors on Unix, HANDLEs on Windows)
The integer itself is meaningless—it's just an index into a kernel table
The kernel maintains mappings from handles to actual resources
When a handle is closed, the mapping is removed
Using a closed handle is undefined behavior (may work, error, or access wrong resource)

Common Handle Types

•File descriptors — References to open files, sockets, pipes (Unix)
•Window handles (HWND) — References to GUI windows (Windows)
•Process handles — References to running processes
•Thread handles — References to threads within a process
•Semaphore/Mutex handles — References to synchronization primitives
•Registry key handles — References to Windows registry entries
•Device contexts (HDC) — References to graphics drawing surfaces
•Timer handles — References to OS timers

The handle lifecycle:

┌────────────────────────────────────────────────────────────┐
│                     HANDLE LIFECYCLE                        │
├────────────────────────────────────────────────────────────┤
│                                                            │
│   [Invalid]                                                │
│       │                                                    │
│   Acquire (open, create, connect)                          │
│       ▼                                                    │
│   [Valid] ──────────► Use (read, write, query)            │
│       │                     │                              │
│       │                     ▼                              │
│       │               May become stale                     │
│       │               (remote close, timeout)              │
│       │                     │                              │
│       ▼                     ▼                              │
│   Release (close, dispose)                                 │
│       │                                                    │
│       ▼                                                    │
│   [Invalid] ◄────────── Handle reused                      │
│                         for new resource!                  │
│                                                            │
└────────────────────────────────────────────────────────────┘

Handle reuse hazard:

When a handle is closed, its integer value becomes available for reuse. If you:

Open file A → get handle 5
Close file A → handle 5 returned to free pool
(Bug) Save 'stale' reference to handle 5
Open file B → get handle 5 (reused!)
Use stale reference → operates on file B, not A!

This is why using closed handles is undefined behavior, not a clean error.

handle-hazards.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
import os
 
# Demonstrating handle reuse hazard (educational only!)
def handle_reuse_hazard():
    # Open a file, get file descriptor
    fd1 = os.open("/tmp/file1.txt", os.O_CREAT | os.O_WRONLY)
    print(f"File 1 descriptor: {fd1}")  # e.g., "3"
    
    # Close the file - handle is now invalid
    os.close(fd1)
    
    # Open another file - might get the same descriptor!
    fd2 = os.open("/tmp/file2.txt", os.O_CREAT | os.O_WRONLY)
    print(f"File 2 descriptor: {fd2}")  # Possibly also "3"!
    
    # If fd1 == fd2 (handle reused), and we have a 'stale' fd1 reference:
    # Writing to fd1 would actually write to file2!
    
    # ❌ Bug: using stale handle
    # os.write(fd1, b"Meant for file 1")  # Would write to file 2!
    
    os.close(fd2)
 
# ✅ ALWAYS set handles to None/invalid after closing
class SafeFileHandle:
    def __init__(self):
        self._fd: int | None = None
    
    def open(self, path: str) -> None:
        self._fd = os.open(path, os.O_CREAT | os.O_RDWR)
    
    def close(self) -> None:
        if self._fd is not None:
            os.close(self._fd)
            self._fd = None  # Mark as invalid immediately
    
    def write(self, data: bytes) -> int:
        if self._fd is None:
            raise RuntimeError("Handle is not open")
        return os.write(self._fd, data)

Thread and Process Resources

Threads and processes are execution resources—they represent active computation capacity. Unlike passive resources (files, connections), these are active entities that consume CPU time, have their own state, and may hold other resources.

Thread resources include:

Thread handle — Reference to the thread for control operations
Thread stack — Dedicated memory for the thread's call stack (typically 1-8 MB)
Thread-local storage — Per-thread variable storage
Scheduling state — Kernel priority queue position
Any resources the thread acquires — Files, connections, locks it holds

Thread vs. Process Resource Overhead
Resource Aspect	Thread (within process)	Process (separate)
Memory overhead	~1-8 MB (stack)	~20-50 MB (address space)
Creation time	~10-100 μs	~1-100 ms
Context switch	~1-10 μs	~10-100 μs
Memory isolation	None (shared heap)	Full (separate address spaces)
Failure isolation	None (crash kills process)	Full (crash isolated)
Communication cost	Cheap (shared memory)	Expensive (IPC)

Thread pool pattern:

Like connection pools, thread pools amortize creation cost and bound resource usage:

Pre-create a set of worker threads
Tasks are submitted to a queue
Idle workers take tasks from the queue
Completed workers return to idle pool

Thread pools transform 'spawn thread for each task' into 'submit task to pool.'

Process resources and zombies:

When a child process completes, it enters a 'zombie' state until the parent:

Calls wait() or waitpid() to collect exit status
The parent itself exits (init/systemd then cleans up)

Failing to wait for child processes creates zombie processes that consume PID table entries, potentially exhausting available PIDs.

thread-pool.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
import { Worker, isMainThread, parentPort, workerData } from 'worker_threads';
 
// Simple thread pool implementation concept
class ThreadPool {
    private workers: Worker[] = [];
    private taskQueue: Array<{
        task: any;
        resolve: (value: any) => void;
        reject: (error: any) => void;
    }> = [];
    private availableWorkers: Set<Worker>;
 
    constructor(private size: number, private workerScript: string) {
        this.availableWorkers = new Set();
        this.initializeWorkers();
    }
 
    private initializeWorkers(): void {
        for (let i = 0; i < this.size; i++) {
            const worker = new Worker(this.workerScript);
            this.workers.push(worker);
            this.availableWorkers.add(worker);
            
            worker.on('message', (result) => {
                this.availableWorkers.add(worker);
                this.processQueue();
            });
            
            worker.on('error', (error) => {
                // Worker crashed - replace it
                this.replaceWorker(worker);
            });
        }
    }
    
    private replaceWorker(deadWorker: Worker): void {
        const index = this.workers.indexOf(deadWorker);
        const newWorker = new Worker(this.workerScript);
        this.workers[index] = newWorker;
        this.availableWorkers.add(newWorker);
        // Set up message handlers...
    }
 
    async execute<T>(task: any): Promise<T> {
        return new Promise((resolve, reject) => {
            this.taskQueue.push({ task, resolve, reject });
            this.processQueue();
        });
    }
    
    private processQueue(): void {
        while (this.taskQueue.length > 0 && this.availableWorkers.size > 0) {
            const { task, resolve, reject } = this.taskQueue.shift()!;
            const worker = this.availableWorkers.values().next().value;
            this.availableWorkers.delete(worker);
            
            worker.once('message', resolve);
            worker.once('error', reject);
            worker.postMessage(task);
        }
    }
 
    // ✅ Critical: Clean up all workers on shutdown
    async shutdown(): Promise<void> {
        const terminations = this.workers.map(w => w.terminate());
        await Promise.all(terminations);
        this.workers = [];
        this.availableWorkers.clear();
    }
}

Threads Holding Resources

Threads often hold other resources (connections, locks, file handles). If a thread is terminated or abandoned without cleanup, those resources leak. Thread termination must include cleanup of all resources the thread acquired during execution.

Specialized Resources

Beyond the core resource types, many specialized resources exist in specific domains:

Synchronization resources:

Locks/Mutexes — Exclusive access to shared state
Semaphores — Counted access control
Read-write locks — Multiple readers or single writer
Condition variables — Wait/signal coordination
Distributed locks — Cross-process/machine mutual exclusion

Synchronization resources are dangerous because leaking them (holding indefinitely) causes deadlocks rather than exhaustion.

Graphics & GPU Resources

•GPU memory buffers
•Shaders (compiled programs)
•Textures and surfaces
•Render targets/framebuffers
•Display contexts
•Compute pipelines

External Service Resources

•API rate limit quotas
•OAuth tokens (with refresh)
•Session cookies
•Cloud service handles
•Queue subscriptions
•Webhook registrations

Timer and scheduling resources:

OS timers — Kernel-scheduled callbacks
Scheduled tasks — Cron jobs, task scheduler entries
Delayed messages — Queue messages with scheduled delivery
Event subscriptions — Registered callbacks for events

These are often overlooked because they don't block on acquire. But they consume memory and kernel resources, and failing to cancel them causes memory leaks and unexpected callbacks.

Cache entries as resources:

Cache entries, while just memory, behave as resources when they:

Have explicit expiration that must be managed
Hold references to other resources
Consume quota space that could be needed by others
Require explicit invalidation on data changes

specialized-resources.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// Timer resources example
class OrderProcessor {
    private reminderTimers = new Map<string, NodeJS.Timeout>();
    
    async processOrder(orderId: string): Promise<void> {
        // Schedule reminder
        const timer = setTimeout(() => {
            this.sendReminder(orderId);
        }, 24 * 60 * 60 * 1000); // 24 hours
        
        this.reminderTimers.set(orderId, timer);
    }
    
    async completeOrder(orderId: string): Promise<void> {
        // ✅ Clean up timer resource when no longer needed
        const timer = this.reminderTimers.get(orderId);
        if (timer) {
            clearTimeout(timer);
            this.reminderTimers.delete(orderId);
        }
        
        await this.markComplete(orderId);
    }
    
    // ✅ Cleanup all timers on shutdown
    shutdown(): void {
        for (const timer of this.reminderTimers.values()) {
            clearTimeout(timer);
        }
        this.reminderTimers.clear();
    }
}
 
// Distributed lock example
import { RedisLock } from './redis-lock';
 
async function processExclusively(resourceId: string): Promise<void> {
    const lock = new RedisLock(redis);
    
    // Acquire distributed lock
    const acquired = await lock.acquire(`resource:${resourceId}`, {
        ttl: 30000,        // Auto-expire after 30s (safety)
        retryDelay: 100,   // Retry every 100ms if not acquired
        retryCount: 50,    // Give up after 50 retries
    });
    
    if (!acquired) {
        throw new Error('Could not acquire lock');
    }
    
    try {
        await doExclusiveWork(resourceId);
    } finally {
        // ✅ ALWAYS release lock, even on error
        await lock.release();
    }
}

Summary: Resource Categories

We've surveyed the major categories of resources you'll encounter in production software systems. Let's consolidate:

Key Takeaways

•Memory resources range from GC-managed heap to native allocations; caches especially need bounded sizing.
•File resources include the descriptor, buffers, and locks; descriptor limits can cause cascading failures.
•Connection resources are expensive to create; pooling is essential; leaks cause death spirals.
•Handle resources are opaque tokens that can be reused after close; stale handles are dangerous.
•Thread/process resources consume both memory and scheduling capacity; pools amortize creation cost.
•Specialized resources include locks (deadlock risk), timers (leak callbacks), and external service quotas.
•Each resource type has unique failure modes — understanding them prevents production incidents.

What's next:

Now that we understand the types of resources, we'll examine the resource lifecycle in detail—the phases every resource goes through from creation to destruction, and how these phases inform management patterns.

Page Complete

You now have a comprehensive taxonomy of resource types used in production software systems. This knowledge allows you to recognize resource responsibilities whenever you encounter them in code and apply appropriate management patterns. Next, we'll explore the resource lifecycle in depth.