Memory, References, and Resource Management

Introduction

A program does more than calculate values. It creates objects, stores data, obtains resources, shares information, and eventually releases what it no longer needs. Understanding memory and resource management is therefore essential for writing reliable software.

C++, Java, and Python use different memory models. C++ gives programmers direct control over addresses, object lifetime, and many resources. Java and Python hide most memory-management details behind automatic garbage collection, although programmers must still understand object references, mutability, ownership, and non-memory resources such as files and network connections.

A useful distinction is between memory management and resource management. Memory is one kind of resource, but programs also use files, database connections, sockets, locks, operating-system handles, and graphics objects. Garbage collection can reclaim unreachable memory; it cannot always close or release external resources at the correct time.

Learning Objectives

By the end of this chapter, you should be able to:

• compare stack and heap storage;
• explain pointers, references, and object identity;
• describe object construction, use, and destruction;
• distinguish manual memory management from garbage collection;
• apply smart pointers and ownership principles in C++;
• explain copying, aliasing, mutability, and value semantics;
• select safe resource-management practices in C++, Java, and Python;
• identify common memory errors and design improvements.

1. Storage Areas and Object Lifetime

Stack and heap

The terms stack and heap describe common storage strategies, but their exact implementation is language- and system-dependent.

The stack normally stores function-call information, including local variables, parameters, return locations, and saved execution state. Stack allocation and deallocation are usually fast and follow last-in, first-out order. A local object commonly ends when its function or block ends.

The heap is a region used for dynamically allocated objects whose lifetime or size is not conveniently tied to a function call. Heap allocation is more flexible but usually involves additional bookkeeping and may be slower. In Java and Python, most objects are created in managed heap storage. In C++, objects may exist in automatic storage, dynamic storage, static storage, or other implementation-defined locations.

A variable stored on the stack may contain a value directly or may contain a pointer/reference to an object on the heap. Thus, “stack variable” does not necessarily mean that the referenced object is on the stack.

Scope, lifetime, and reachability

Scope describes where a name can be used in source code. Lifetime describes how long the object exists. Reachability describes whether an object can still be accessed through a chain of live references.

These ideas are related but not identical. A variable can leave scope while the object it referenced remains alive because another reference exists. Conversely, a C++ object may be destroyed at the end of a scope even if a copied pointer still contains its address; that pointer then becomes invalid.

In C++, a local object has a predictable lifetime. In Java and Python, an object becomes eligible for garbage collection when it is no longer reachable, but collection time is not normally predictable.

2. Pointers and References

Pointers

A pointer is a value representing a memory address or, more precisely, an address-like location. In C++, pointers can be dereferenced to access an object:

int score = 85;
int* p = &score;
*p = 90;

Here, p stores the address of score, and *p denotes the object reached through that address. A pointer may be null, may be changed to point elsewhere, and may participate in pointer arithmetic for suitable arrays.

Pointers are powerful but dangerous. A null-pointer dereference accesses no valid object. A dangling pointer refers to an object whose lifetime has ended. An uninitialised pointer contains an indeterminate value. A wild pointer is an informal term for an invalid or uncontrolled pointer. C++ programmers must prevent these states.

Java and Python do not expose ordinary raw memory pointers in application code. Their variables contain references to objects, but the language runtime controls object locations and prevents ordinary pointer arithmetic.

References

A C++ reference is an alias for an existing object:

void increase(int& value) {
    ++value;
}

The parameter value refers to the caller’s object. A reference normally must be bound when created, cannot be reseated, and should not be used to represent “no object”; a pointer is more appropriate when null is meaningful.

Java and Python use the word reference differently. A Java or Python variable may refer to an object, and several variables may refer to the same object. These references are assignable: after a = b, a refers to the same object as b. They are not C++ reference variables, even though the practical effect includes aliasing.

3. Object Lifecycle

An object lifecycle commonly includes:

1. allocation of storage;
2. initialization or construction;
3. active use;
4. possible copying, moving, or sharing;
5. finalization or destruction;
6. release of associated resources.

In C++, constructors establish class invariants and destructors release resources. A local object is destroyed automatically when its scope ends, including during exception handling. This predictable mechanism supports RAII—Resource Acquisition Is Initialization. Under RAII, an object acquires a resource in its constructor and releases it in its destructor.

#include <fstream>

void write_report() {
    std::ofstream file("report.txt");
    file << "Completed\n";
} // file closes automatically here

The example is safer than requiring every exit path to call close() manually.

Java provides constructors but does not provide deterministic destructor calls. The try-with-resources statement should be used for objects implementing AutoCloseable:

try (var file = new java.io.BufferedWriter(
        new java.io.FileWriter("report.txt"))) {
    file.write("Completed\n");
}

Python commonly uses context managers:

with open("report.txt", "w") as file:
    file.write("Completed\n")

The with statement ensures the context manager’s cleanup protocol is invoked when the block exits, including through an exception.

4. Manual Memory Management and Garbage Collection

C++ manual and automatic techniques

C++ supports dynamic allocation with new and delete, but direct ownership is error-prone:

int* p = new int(42);
// use *p
delete p;

Every successful allocation must have exactly one appropriate release. Failure can produce a memory leak, double deletion, or use-after-free. Modern C++ therefore recommends avoiding explicit new and delete in application code where standard library containers and smart pointers can express ownership more safely.

Garbage collection

Java and Python use tracing garbage collectors. A collector identifies objects that are no longer reachable from roots such as active local variables, static data, or runtime structures, and reclaims their memory. Collection may be triggered by allocation pressure or runtime policy.

Garbage collection provides important safety benefits:

• unreachable memory can be reclaimed automatically;
• ordinary double-free errors are avoided;
• object locations may be changed internally by a compacting collector;
• programmers can focus on object relationships rather than raw addresses.

It does not guarantee immediate reclamation. It also does not prevent logical memory leaks: a program may retain references in a cache, list, listener, or global variable even though it no longer needs the objects.

Garbage collection is not a substitute for closing files, releasing locks, returning database connections, or cancelling operations. Those resources require explicit lifecycle protocols such as Java’s close(), Python context managers, or library-specific release methods.

5. Smart Pointers and Ownership in C++

A smart pointer is an object that manages a pointer according to an ownership policy.

Example:

#include <memory>

auto item = std::make_unique<int>(42);

item owns the integer. Ownership can be transferred but not copied:

auto second = std::move(item);

After the move, second owns the object and item is empty. A moved-from object remains valid for destruction, reassignment, and operations allowed by its type, but its previous resource ownership should not be assumed.

Shared ownership is appropriate only when ownership really is shared:

auto first = std::make_shared<int>(42);
auto second = first;

Both smart pointers contribute to the object’s lifetime. Reference counting usually reclaims the object when the last owning shared_ptr is destroyed. However, cycles can prevent reclamation:

A owns B; B owns A

A weak_ptr represents an observation without keeping the object alive and can break such cycles. Smart pointers do not make every program safe: incorrect ownership design, data races, excessive shared ownership, and dangling raw pointers obtained through .get() remain possible.

6. Copying, Assignment, Aliasing, and Mutability

Copying and identity

A value is the data represented by an object. Identity is the fact that an object is a particular entity in memory or runtime storage. Two objects may have equal values but different identities.

A shallow copy duplicates an outer object while preserving references to nested objects. A deep copy duplicates the nested objects as well. Consider a list containing another list in Python:

original = [[1, 2]]
shallow = original.copy()
shallow[0].append(3)

Both variables refer to different outer lists, but their first elements refer to the same inner list. Therefore, the inner modification is visible through original too.

In Java, assignment of an object variable copies a reference, not the object. In C++, ordinary copying of a class object may copy its members. If a class owns a raw resource, the default copy operation may be unsafe; the class should implement appropriate copy/move operations or use resource-managing members.

Mutability and const-correctness

A mutable object can change its state after creation. An immutable object cannot be changed; an apparent modification creates another value or fails.

Aliasing becomes risky when one mutable object is reachable through multiple names. A function may unexpectedly change a caller’s data if it receives a mutable reference or shared object. Safe designs document ownership and mutation, use immutable values where practical, and make interfaces explicit.

C++ supports compile-time restrictions with const:

void display(const std::string& text);

This avoids copying the string while promising that the function will not modify it through that reference. Java uses final to prevent reassignment of a variable, but a final reference does not make the referenced object immutable. Python has no universal immutability qualifier; tuples, strings, and carefully designed classes can provide immutable behaviour.

7. Resource-Management Patterns

A robust design answers four questions:

1. Who owns the resource?
2. When does ownership begin?
3. When and how does ownership end?
4. What happens when an operation fails or raises an exception?

Ownership and borrowing

Ownership grants responsibility for releasing a resource. Borrowing grants temporary access without transferring responsibility. Function interfaces should distinguish these roles. In C++, a reference or raw pointer can represent a non-owning parameter when documented and guaranteed valid for the call; a smart pointer communicates ownership more clearly.

Exception safety

An exception may leave a function through many paths. Cleanup must therefore be automatic or placed in a guaranteed cleanup construct. C++ RAII, Java try-with-resources, and Python with statements all implement this principle.

C++ exception-safety guarantees are often described as:

• no-throw guarantee: the operation does not throw;
• strong guarantee: failure leaves the program state unchanged;
• basic guarantee: invariants remain valid and no resources leak;
• no guarantee: callers cannot rely on safe state after failure.

Professional code should provide at least the basic guarantee for resource-managing operations.

Common failures

• Memory leak: allocated memory remains unreachable or unnecessarily retained.
• Use-after-free: code accesses an object after its lifetime ends.
• Double free: a resource is released more than once.
• Dangling reference: an alias outlives its target.
• Exhaustion: files, sockets, handles, or memory are not returned promptly.
• Ownership cycle: mutually retaining objects prevent reclamation.

Testing, sanitizers, static analysis, code review, and clear interfaces help detect these faults. In C++, AddressSanitizer can expose many out-of-bounds and use-after-free errors. Profilers and heap-analysis tools can help investigate leaks. Java and Python developers can inspect heap profiles and retained-reference paths.

Applied Case: A Student Records Service

The following is an illustrative case.

Background

A college service stores student records and exports them to a file. The first C++ implementation allocates records with new, stores raw pointers in a global vector, and opens the output file manually.

Problem

Records are deleted in one error path but not another, causing leaks. A sorting function keeps a pointer to a record after the record is removed. In addition, two modules both believe they own the same record and attempt to delete it.

Analysis

The design has unclear ownership, raw-pointer lifetime hazards, and non-automatic file cleanup. The sorting function needs temporary access, not ownership. The collection should own each record exactly once.

Approach

The service is redesigned as follows:

std::vector<std::unique_ptr<Student>> records;
records.push_back(std::make_unique<Student>(1234, "Amina").release());

The shown insertion is not ideal because it releases ownership into a raw pointer; a safer form is:

records.push_back(std::make_unique<Student>(1234, "Amina"));

Functions that only inspect a student receive const Student&. A function that may observe an optional student receives a pointer or another explicitly optional form, with a documented lifetime. The export operation uses std::ofstream, whose destructor closes the file.

Outcome

Each record has one clear owner, deletion occurs automatically, and exception paths do not leak records or files. The design also makes mutation visible in function signatures.

Learning points

Ownership should be represented in the type system where possible. Non-owning access should not be confused with ownership. Automatic cleanup is especially valuable when operations can fail.

8. Professional, Ethical, and Contemporary Considerations

Memory errors can become security vulnerabilities. Out-of-bounds writes may corrupt control data; use-after-free may expose or alter sensitive information; retained objects may preserve personal data longer than necessary. Secure development therefore includes input validation, least privilege, secure erasure requirements where applicable, dependency updates, and privacy-aware retention policies.

Developers should not assume that garbage collection erases sensitive data immediately. Copies may exist in buffers, logs, swap space, or temporary objects. When handling credentials or personal records, use established security libraries and follow organisational and legal requirements rather than relying on ad hoc memory clearing.

Modern language design increasingly combines static analysis, ownership systems, safer standard libraries, and runtime checks. C++ continues to improve library support for RAII and safer abstractions. Java and Python provide mature context-management patterns and profiling tools. AI coding assistants can suggest resource-management code, but generated code must be reviewed for ownership, exception paths, data races, and library-specific lifecycle rules. Responsibility for correctness remains with the developer.

Best-Practice Checklist

• Prefer automatic storage and standard containers where suitable.
• In C++, prefer RAII, make_unique, and make_shared over explicit new and delete.
• Use unique_ptr by default when dynamic ownership is exclusive.
• Use shared_ptr only when shared lifetime is a genuine requirement.
• Use weak, non-owning relationships to prevent ownership cycles.
• Never return or store a reference to a local object after its scope ends.
• Distinguish copying a value from copying a reference.
• Treat mutable shared state as a coordination and correctness risk.
• Close non-memory resources deterministically.
• Test failure paths, not only successful paths.
• Use sanitizers, static analysis, profiling, and code review.

Chapter Summary

Stack storage is commonly associated with call scopes, while heap storage supports dynamically managed objects; the distinction is useful but implementation-dependent. Pointers expose address-based access and therefore create risks such as dangling pointers and double deletion. References and object references provide aliasing without necessarily transferring ownership.

C++ supports predictable destruction and RAII, while Java and Python use garbage collection for unreachable memory. Garbage collection does not replace deterministic release of files, locks, sockets, or other external resources. Smart pointers express ownership in C++, with unique_ptr for exclusive ownership, shared_ptr for genuine shared ownership, and weak_ptr for non-owning observation.

Copying, aliasing, identity, and mutability determine whether changes are shared or independent. Safe professional designs define ownership, make lifetimes clear, use automatic cleanup, handle exceptions, and treat memory safety as part of security and ethical software engineering.

Key Terms

Memory management: Organising allocation, use, and reclamation of memory.

Resource management: Controlling the lifetime of memory and external resources.

Stack: Common call-oriented storage with scope-related lifetime.

Heap: Dynamic storage used for objects with flexible lifetimes.

Pointer: An address-like value used to locate an object.

Reference: An alias or runtime connection to an object.

Scope: Region of source code where a name is visible.

Lifetime: Period during which an object exists.

Reachability: Whether an object can be accessed from live roots.

Dangling pointer: A pointer to an object whose lifetime has ended.

RAII: C++ practice of binding resource release to object lifetime.

Garbage collection: Automatic reclamation of unreachable managed objects.

Smart pointer: An object that applies an ownership policy to a pointer.

Ownership: Responsibility for controlling and releasing a resource.

Borrowing: Temporary access without ownership transfer.

Aliasing: Multiple names or references accessing one object.

Shallow copy: Copying an outer object while sharing nested objects.

Deep copy: Copying an object and its relevant nested objects.

Mutability: Ability of an object to change state.

Exception safety: Correct resource and state behaviour when operations fail.

Review Questions

5 Short Answer Questions

1. What is the difference between scope and lifetime?
2. Why is a dangling pointer dangerous?
3. What problem does RAII solve in C++?
4. Why does garbage collection not remove the need to close files?
5. When is std::weak_ptr useful?

5 Long Answer Questions

1. Compare stack and heap storage in C++, Java, and Python.
2. Explain the lifecycle of a dynamically managed object and identify possible failure points.
3. Compare raw pointers, references, unique_ptr, and shared_ptr in C++.
4. Explain shallow copying, deep copying, aliasing, and mutability using examples.
5. Compare C++ RAII, Java try-with-resources, and Python context managers.

3 Analytical / Application Questions

1. A C++ program stores raw pointers to objects that are deleted by two different modules. Analyse the faults and propose an ownership redesign.
2. A Python service retains every request object in a global list. Explain why garbage collection does not solve the resulting memory problem and recommend controls.
3. Design a resource-management strategy for a Java application that reads a database result, writes a report, and may fail during processing. Explain how cleanup is guaranteed.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes scope from lifetime?

A. Scope is where a name is visible; lifetime is how long the object exists.

B. Scope is the amount of heap used; lifetime is the amount of stack used.

C. Scope applies only to Java; lifetime applies only to C++.

D. Scope and lifetime always mean exactly the same thing.

Correct Answer: A. Scope is where a name is visible; lifetime is how long the object exists.

Question 2

What is the primary purpose of std::unique_ptr?

A. To permit unlimited pointer arithmetic

B. To express exclusive ownership with automatic cleanup

C. To disable object destruction

D. To create a garbage collector

Correct Answer: B. To express exclusive ownership with automatic cleanup

Question 3

What happens when a C++ pointer is dereferenced after its target has been destroyed?

A. The pointer automatically recreates the object

B. The pointer becomes a safe null pointer

C. The program performs a potentially invalid use-after-free

D. The compiler converts it into a reference

Correct Answer: C. The program performs a potentially invalid use-after-free

Question 4

Which construct provides deterministic cleanup for a Python file?

A. A global variable

B. A with statement using a context manager

C. A copied list

D. A reference count written by the programmer

Correct Answer: B. A with statement using a context manager

Question 5

Why can a cycle of two shared_ptr objects cause a memory leak?

A. Neither object can be compiled

B. Each object keeps the other’s reference count from reaching zero

C. shared_ptr always deletes objects twice

D. Cycles move all objects to stack storage

Correct Answer: B. Each object keeps the other’s reference count from reaching zero

Question 6

In Java, assigning one object variable to another normally copies what?

A. The complete object and all nested objects

B. Only the object’s class definition

C. A reference to the object

D. The object’s operating-system process

Correct Answer: C. A reference to the object

Question 7

Which C++ feature most directly supports automatic release when a local object leaves scope?

A. RAII and destructors

B. Pointer arithmetic

C. Global mutable state

D. Manual memory inspection only

Correct Answer: A. RAII and destructors

Question 8

What is a shallow copy likely to do when an object contains a nested mutable object?

A. Always make every nested object independent

B. Share the nested object between the copies

C. Destroy the nested object

D. Convert the nested object into a stack frame

Correct Answer: B. Share the nested object between the copies

Question 9

Which resource-management approach is safest for a C++ collection that exclusively owns dynamically created students?

A. A vector of unique_ptr<Student>

B. A vector of uninitialised pointers

C. Two modules independently deleting every student

D. Returning references to destroyed local students

Correct Answer: A. A vector of unique_ptr<Student>

Question 10

Why can a garbage-collected program still suffer a logical memory leak?

A. Garbage collectors delete reachable objects too early

B. The program may retain references to objects it no longer needs

C. Garbage collection applies only to stack variables

D. Garbage collection disables all object allocation

Correct Answer: B. The program may retain references to objects it no longer needs