Efficient Memory Allocation with a Pool Allocator in Go

Memory allocation can be a performance bottleneck in many applications, especially those dealing with frequent object creation and destruction. A pool allocator reuses pre-allocated objects, reducing the overhead of repeated calls to the system allocator. This challenge asks you to implement a simple pool allocator in Go to improve memory management efficiency for a specific type.

Problem Description

You are tasked with creating a PoolAllocator in Go that manages a pool of Item structs. The Item struct has a single integer field. The pool allocator should allow you to:

1. Get: Retrieve an Item from the pool. If the pool is empty, it should allocate a new Item and add it to the pool.
2. Release: Return an Item to the pool, making it available for reuse.
3. Size: Return the current number of items in the pool.
4. Capacity: Return the maximum number of items the pool can hold.

The pool should be initialized with a specified capacity. When an item is retrieved, its Value field should be initialized to 0. When an item is released, its Value field should be reset to 0. The pool should be thread-safe to allow concurrent access from multiple goroutines.

Key Requirements:

• Implement a thread-safe pool allocator.
• Handle cases where the pool is empty and needs to allocate a new item.
• Reset the Value field of released items to 0.
• Provide methods for getting, releasing, getting the size, and getting the capacity of the pool.

Expected Behavior:

• Get() should return a pointer to an Item (either from the pool or newly allocated).
• Release() should return the Item pointer to the pool.
• Size() should return the number of items currently in the pool.
• Capacity() should return the maximum number of items the pool can hold.

Edge Cases to Consider:

• Pool capacity of 0.
• Concurrent access to the pool from multiple goroutines.
• Releasing an item that was not obtained from the pool (should not panic, but ideally handle gracefully).

Examples

Example 1:

Input: capacity = 5
Get() -> Item{Value: 0}
Get() -> Item{Value: 0}
Size() -> 2
Release(item1)
Release(item2)
Size() -> 4

Explanation: The pool is initialized with a capacity of 5. Two items are retrieved, increasing the size to 2. Then, both items are released back into the pool, increasing the size to 4.

Example 2:

Input: capacity = 2
Get() -> Item{Value: 0}
Get() -> Item{Value: 0}
Get() -> Item{Value: 0}
Size() -> 2
Capacity() -> 2

Explanation: The pool is initialized with a capacity of 2. Two items are retrieved. The third Get() call allocates a new item because the pool is empty, bringing the size to 2 (the capacity).

Example 3: (Concurrent Access)

Input: capacity = 10
// Multiple goroutines concurrently call Get() and Release()
// After a period of time:
Size() -> 7
Capacity() -> 10

Explanation: Multiple goroutines access the pool concurrently. The size fluctuates based on the number of items acquired and released. The capacity remains constant.

Constraints

• The Item struct has a single integer field named Value.
• The pool capacity must be a non-negative integer.
• The pool must be thread-safe. Use appropriate synchronization primitives (e.g., sync.Mutex).
• The Get() method should return a pointer to an Item.
• The Release() method should accept a pointer to an Item and return nothing.
• The Size() method should return an integer representing the number of items in the pool.
• The Capacity() method should return an integer representing the maximum capacity of the pool.
• Performance: The overhead of Get() and Release() should be minimal compared to a direct allocation/deallocation from the system allocator.

Notes

Consider using a sync.Mutex to protect access to the pool's internal data structures. A slice can be used to store the pool of items. Think about how to efficiently manage the pool's state (e.g., tracking available and allocated items). The goal is to minimize allocations and deallocations to the system allocator. Don't overcomplicate the implementation; a simple and correct solution is preferred. Error handling is not required for this challenge.