Apple Game Developer (Mid-Level) Interview Preparation Guide

Situation: On a launch project, my team owned the API work and the partner team owned the customer-facing workflow. We both wanted the same release date, but their priority was polish while mine was integration stability.

Task: I needed to keep both sides moving even as trade-offs came up.

Action: I set up a shared plan with one clear owner per dependency, then separated must-have work from nice-to-have work. I also defined the term "trade-off" for the group as a choice where we gain one benefit by giving up another, so the conversation stayed concrete. When design wanted an extra step and engineering needed more time for testing, I asked, "What is the smallest version that still protects the user and the launch date?" We agreed to ship the core flow first, keep one optional enhancement for later, and review progress twice a week.

Result: We delivered the shared goal on time with a smaller scope, and both teams felt heard. I learned that progress keeps moving when you make the decision criteria explicit instead of debating opinions.

High-level goal
Step-by-step workflow to isolate periodic CPU frame-time spikes and decide whether they come from (a) main-thread script, (b) rendering, (c) GC, or (d) native OS activity.

1) Reproduce & collect Android Profiler traces

• Run game on target device, open Android Studio Profiler.
• Capture a CPU trace (sampling or instrumented) during spike window.
• Also record Memory and System Trace (or Perfetto) for the same interval.
  What to inspect:
• CPU: thread list, top methods, call stacks at spike time.
• System Trace: thread scheduling, CPU frequency changes, IRQs, binder activity.

2) Check main-thread script code

• In Android Profiler CPU trace, open the main/UI/game thread.
• Look for long-running methods, high cumulative time, frequent call patterns.
• In Unity: run Unity Profiler (IL2CPP/Mono) with Deep Profiling off, collect CPU timeline; inspect "Main Thread", "Script" categories and method samples. Enable "Deep Profile" for narrow windows.
• In Unreal: use stat startfile/Unreal Frontend frame capture; inspect GameThread timings.
  If main-thread methods line up with spikes → script logic is culprit.

3) Check rendering

• In Android trace, inspect RenderThread and GPUFence wait times; check frame pacing gaps.
• In Unity: use Frame Debugger and Unity Profiler Rendering module (Camera.Render, SRP/HDRP, draw calls, SRP Batches). Capture GPU profiler via adb shell am profile or GPU profiling tools.
• In Unreal: use GPU profiler (profilegpu) and render thread timings.
  If RenderThread or GPU waits coincide → rendering or draw-call/compositor bottleneck.

4) Check garbage collection

• Open Memory profiler and Mono/Native heap traces.
• In Unity Profiler look for GC.Alloc spikes and "GC.Collect" events on timeline; inspect allocation rate and Gen0/Gen1 collections.
• In Unreal, inspect UObject GC stats and tick spikes around GC passes.
  If GC events align with spikes and free-list work is high → GC-induced.

5) Check native OS activity

• Inspect System Trace / Perfetto: kernel scheduling, CPU hotplug, frequency throttling, IRQs, binder transactions, wakelocks.
• Use adb shell top, dumpsys batterystats, and systrace to see other processes consuming CPU.
• Correlate timestamps: if spike aligns with scheduler churn, CPU frequency change, or another PID → native OS activity.

6) Narrow & validate

• Instrument suspected code paths (timers, logging) and rerun.
• For scripting: add sampling timers, reduce workload and confirm spike reduction.
• For rendering: reduce resolution, disable effects to see effect.
• For GC: reduce allocations, enable incremental GC or switch allocator; confirm mitigation.
• For native: try on a clean device or disable background services.

Summary: collect CPU + System Trace + Memory; inspect main thread call stacks, RenderThread/GPU waits, GC events, and OS-level scheduling/IRQ/freq changes. Correlate timestamps across traces to identify root cause.

Direct answer

Build a standing information diet from what the partner function already produces for itself, its goals or planning document, the metrics it is measured on, and its retro or release notes, and pair that with a recurring informal check-in with one counterpart in that function. You are not trying to get invited into their planning meeting; you are trying to read what they optimize for, and occasionally confirm your read against a real person.

Structured elaboration

The habit that ties these together: translate their metric into one sentence you could say back to them and have them agree it is accurate, then test that sentence the next time you talk. If you cannot state their current priority in a sentence they would sign off on, your information diet has a gap.

Worked example

Suppose you regularly partner with a support or customer-success function but are not in their planning. Their quarterly goals page (a document they publish for their own team) states the goal is "reduce median response time." Reading that before proposing a change that would meaningfully increase inbound volume lets you flag the likely trade-off to your counterpart ahead of launch, rather than finding out after the fact that you worked against their stated goal. The artifact told you what they were measured on; the counterpart conversation confirmed it was still current.

Trade-offs & pitfalls

• Relying only on artifacts risks reading a goal that is stale or aspirational and no longer reflects what the team is actually prioritizing day to day.
• Relying only on a single counterpart's opinion risks mistaking one person's take for the function's actual priority, especially if that person is not close to how the team's metrics are reviewed.
• A common miss: reading the dashboard but never validating the interpretation with anyone in that function, which produces confidently wrong assumptions that only surface when a decision already went the wrong way.
• The senior differentiator on an easy-sounding question like this is treating it as a standing habit built before you need it, rather than something you scramble to learn only after a conflict has already surfaced.

Approach (brief)

Use a fixed-size square grid (cellSize) and map 2D integer cell coords to a single 64-bit key (combine x,y). Store Dictionary<long, List<int>> mapping cellKey → entity IDs. QueryNearby checks cells overlapping a circle.

Why this cell size

• Choose cellSize ≈ average entity interaction radius or bounding-box size (e.g., 1.0 unit). Balances number of neighbors to check vs. entities per cell; smaller cells reduce per-cell scans but increase neighbor cells checked.

Implementation

using System;
using System.Collections.Generic;
using UnityEngine;

public class SpatialHash2D {
    private readonly float cellSize;
    private readonly Dictionary<long, List<int>> map = new Dictionary<long, List<int>>();

    public SpatialHash2D(float cellSize) {
        this.cellSize = Mathf.Max(0.0001f, cellSize);
    }

    // world position -> cell coords
    public (int x, int y) Vector2ToCell(Vector2 pos) {
        int x = Mathf.FloorToInt(pos.x / cellSize);
        int y = Mathf.FloorToInt(pos.y / cellSize);
        return (x, y);
    }

    // combine ints into a single key (signed 32 -> 64)
    public long GetCellKey(int x, int y) {
        return ((long)(uint)x << 32) | (uint)y;
    }

    public void Insert(int entityId, Vector2 pos) {
        var (x,y) = Vector2ToCell(pos);
        long key = GetCellKey(x,y);
        if (!map.TryGetValue(key, out var list)) {
            list = new List<int>();
            map[key] = list;
        }
        if (!list.Contains(entityId)) list.Add(entityId);
    }

    public void Remove(int entityId, Vector2 pos) {
        var (x,y) = Vector2ToCell(pos);
        long key = GetCellKey(x,y);
        if (map.TryGetValue(key, out var list)) {
            list.Remove(entityId);
            if (list.Count == 0) map.Remove(key);
        }
    }

    // returns all entity IDs whose cell intersects circle (coarse filtering)
    public List<int> QueryNearby(Vector2 pos, float radius) {
        int minX = Mathf.FloorToInt((pos.x - radius) / cellSize);
        int maxX = Mathf.FloorToInt((pos.x + radius) / cellSize);
        int minY = Mathf.FloorToInt((pos.y - radius) / cellSize);
        int maxY = Mathf.FloorToInt((pos.y + radius) / cellSize);

        var result = new List<int>();
        var seen = new HashSet<int>();
        for (int x = minX; x <= maxX; x++) {
            for (int y = minY; y <= maxY; y++) {
                long k = GetCellKey(x,y);
                if (map.TryGetValue(k, out var list)) {
                    foreach (var id in list) {
                        if (seen.Add(id)) result.Add(id);
                    }
                }
            }
        }
        return result;
    }
}

Complexity

• Insert/Remove: average O(1) to find cell; O(m) to scan list in worst-case where m is entities per cell.
• QueryNearby: O(c + r) where c = number of cells in search box (~(2*ceil(radius/cellSize)+1)^2) and r = unique returned entities.
• Trade-offs: track entity → cell mapping for O(1) removal if many removes; include fine-grained filtering (distance check) after coarse cell query for precise results.

Approach overview
As a game developer I favor explicit ownership, predictable lifetimes, and cheap deletion patterns to avoid dangling refs and leaks. Below I compare patterns and give concrete practices for deletion during iteration.

Manual ownership tree (parent/child)

• Best for scene graphs: parent owns children, deletion cascades.
• Use clear APIs: DetachBeforeDelete(), nullify parent pointers.
• Pitfall: cross-links cause cycles; solve with weak back-pointers.

Reference counting (smart pointers)

• C++: use std::shared_ptr / std::weak_ptr; C#: use patterns with IDisposable and weak events.
• Pros: automatic; Cons: cycles and overhead. Always break cycles with weak_ptr or WeakReference.

ECS + pooling

• Ideal for high-performance games. Entities are IDs; components in packed arrays.
• Use "deferred delete" flags and a single sweep to recycle pooled entities each frame.
• Pools avoid allocation churn and leaks.

Observer/subscription cleanup

• Use weak subscriptions or explicit Unsubscribe in teardown.
• In C#, prefer events + WeakReference or IObservable with IDisposable.

Deletion during iteration

• Don't delete in-place. Options:
  • Mark-for-deletion list and remove after iteration (safe and common).
  • Iterator-safe remove (ECS: swap-remove with index adjustments).
  • Use stable iterators or copy-on-write when necessary.

Rule of thumb
Prefer deterministic lifetime (ownership or deferred destruction) + weak refs for non-owning links. Keep deletion centralized and documented.

Approach summary (as a game developer):
I’d build per-channel semantics over UDP using sequence numbers + per-packet metadata (channel id, seq, reliability flag). Then implement lightweight reliability on top: movement = unreliable (send and forget with sequence for interpolation), chat = reliable-ordered, transactional = reliable-unordered.

Channel implementations

• Movement (unreliable): send seq; clients drop old/out-of-order packets; use dead-reckoning + interpolation. No retransmit.
• Chat (reliable-ordered): assign monotonically increasing seq per-client/channel. Buffer out-of-order packets; deliver to game only when next seq arrives (or after short reordering timeout) to preserve order.
• Transactional (reliable-unordered): reliable delivery but no ordering constraint. Deliver as soon as packet acknowledged and received; use independent seq for deduplication.

ACK strategies

• Cumulative ACK for cheap throughput: server ack highest contiguous seq received per channel — good for movement/ordered chat to reduce ack traffic.
• Selective ACK (SACK): include bitmaps or ranges of missing/received seqs so sender knows exactly what to retransmit — necessary for transactional channel and high-loss links.
• Hybrid: cumulative ACK + SACK options in header for efficiency.

Retransmission & backoff

• Maintain RTT estimate and RTO (like TCP): RTO = SRTT + 4*RTTVAR.
• Exponential backoff with jitter on consecutive failures: RTO *= 2 + random(0..20%).
• Limit max retries; escalate to higher-level error if exceeding attempts (e.g., show “send failed”).

Avoiding congestive collapse

• Prioritize channels: give chat/transactional reliable queues higher send priority than movement or vice‑versa depending on gameplay.
• Server/client pacing: use token-bucket rate limiter per-client and global queueing to smooth bursts.
• Randomized retransmit jitter: add small random delay before retransmit to avoid synchronized storms.
• Backpressure: when many clients retransmit, throttle retransmit rates and prefer cumulative acks to reduce ack implosion.
• Congestion signals: detect rising loss/RTT and reduce send rate for non-critical channels; for critical transactional messages, use server-side aggregation/ack batching.
• Use path MTU, avoid overlarge packets, and consider FEC for movement channel to reduce retransmits in high-loss environments.

This mix gives predictable ordering where needed, efficient ACKs, adaptive retransmit behavior, and safeguards against network-wide retransmit storms while keeping gameplay responsive.

Approach & goals
Design a flexible UI system that preserves composition across phones, tablets, and TVs: consistent margins, readable type, predictable navigation for touch and gamepad, and correct handling of safe areas/notches.

Layout & anchor strategy

• Use relative anchors (center, stretch) not absolute pixels. In Unity: RectTransform anchors + Layout Groups; in Unreal: Anchors + DPI Scale Boxes.
• Define three layout buckets (phone, tablet, TV) with shared constraints; use constraint-driven components (min/max width, aspect-aware breakpoints) to switch layouts or scale elements.

Safe area / notch handling

• Query platform safe-area APIs at startup and on resize; apply safeInset padding to root canvas. For Unity, use Screen.safeArea -> convert to Canvas space and set as outer padding.

Font & DPI scaling

• Use dynamic fonts and scale by device DPI or reference resolution: scaleFactor = deviceDPI / referenceDPI, then clamp to sensible range. Prefer rem-like base font size and scale UI with Canvas scaler (constant physical size or scale with screen match mode).

Input differences

• Abstract input layer: high-level actions (Select, Back, Navigate) mapped to touch, mouse, gamepad.
• For gamepad: ensure focusable UI elements, visible focus indicators, and D-pad/analog deadzone navigation. For touch: larger hit targets and gesture handling.

Testing & validation

• Create an automated layout test rig: render UI under multiple resolutions/aspect ratios and capture screenshots.
• Test matrix: common phone ratios (16:9, 19.5:9), tablets (4:3, 16:10), TVs (16:9, 21:9) and DPIs/scale factors.
• Manual QA: verify safe-area, gamepad focus flow, and input latency on real devices/emulators.

Trade-offs

• Runtime layout switching adds complexity but improves UX; pre-baked layouts reduce CPU cost. Use hybrid: small runtime math + prebuilt variants for big shifts.

Clarify goal & constraints
I’d implement a GPU-driven renderer where culling, LOD selection and generate-of-draws happen entirely on GPU using compute shaders + indirect draws (DrawIndirect / DispatchIndirect). Target APIs: Vulkan/D3D12 (timeline semaphores, ExecuteIndirect). Fallback for older APIs/GPUs included.

Pipeline stages

1. Upload scene metadata

• Per-object AABB / bounding sphere, material & LOD info, model matrices in GPU buffers (SSBO/StructuredBuffer).
• Frustum/clip planes, view/proj matrices, camera info in a uniform.

2. GPU culling (frustum + LOD + coarse occlusion)

• Dispatch compute in workgroups; each thread tests one or small batch of objects.
• Do quick frustum and LOD checks first. For coarse occlusion, use hierarchical Z (hi-Z) generated from depth pre-pass or a coarse depth pyramid sampled in compute.
• Mark visible objects in a bitmask buffer or append to a visibility list using atomic append.

3. Build compact visible-object list

• Two patterns:
  • Atomic-append buffer: each thread that passes appends an object index into an append/consume buffer (fast, lock-free).
  • Bitmap + parallel prefix-sum (scan): set 1/0 per object, run parallel exclusive scan to compute compacted indices then write out list — better when you need counts deterministic or avoid atomics at scale.
• After compaction we have numVisible and an array of visible-object entries.

4. Write Indirect Draw/Dispatch buffers

• For each visible object, compute required DrawArguments (vertexCount, instanceCount, startIndex, baseVertex) or DispatchArguments for compute-based effects and write into an IndirectArgs buffer (structured buffer of Draw/Dispatch args).
• Optionally build multi-draw ranges (multi-draw indirect) grouped by pipeline/material to minimize state changes.

5. Synchronize compute → graphics

• Use GPU-side synchronization only:
  • In Vulkan/D3D12: insert memory barrier / buffer barrier in command buffers; if compute and graphics are same queue, ensure compute dispatches happen before bind/execute of indirect draws in the same command buffer via pipeline barriers.
  • If compute runs on separate queue: use timeline semaphores or binary semaphores + queue submit order to signal completion. Avoid CPU waits (no MapRead).
• Example: Submit compute cmd buffer writing IndirectArgs, signal timeline semaphore value N; submit graphics cmd buffer that waits on semaphore N then issues DrawIndirect.
• Use short-lived GPU fences only for readback or debugging; avoid per-frame CPU waits.

Minimizing stalls

• Double-buffer or ring-buffer per-frame resources to avoid GPU writing same buffers GPU is reading.
• Split culling into coarse and fine passes so heavy occlusion only if needed.
• Batch indirect draws by pipeline state to reduce descriptor/table binds; use bindless descriptors so draw loop is cheap.
• Use multi-frame pipelining: kick compute for frame N+1 while GPU renders frame N.

Fallbacks for older hardware

• No indirect draw support:
  • CPU-driven fallback: do culling on CPU and emit classic draw calls (instanced or batched).
  • Emulate indirect via a small GPU->CPU readback of visible list count (async readback) and then CPU issues draws; keep readback asynchronous and use one-frame latency.
  • Use GPU-driven but with DrawIndexedInstanced with large instance-count and per-instance visibility via vertex shader culling (wasteful but works).
• No compute shaders:
  • Use transform feedback / stream-out or vertex shader culling with layered rendering.
  • Pre-bake occlusion/visibility on CPU or use software occluders.

Trade-offs & notes

• Atomics/append are simple but can serialize under contention—scan-based compaction scales better for huge object counts.
• Hi-Z occlusion cheap but approximate; hardware occlusion queries are accurate but expensive if many objects.
• Prioritize minimising CPU-GPU sync; keep everything GPU-resident and use GPU-only semaphores/fences.

This approach yields low-CPU overhead, scales to many objects, and gracefully degrades for older hardware by moving culling and indirect generation back to CPU or hybrid async readback.

Direct answer
I treat a company's published culture and values as a claim to be tested, not a fact to accept, and I look for evidence in three places: how people describe real, specific incidents (not slogans) when I ask about them, whether the org's actual structures and incentives would make the stated behavior easy or hard to practice, and whether the story is consistent across different people I talk to in the process.

Structured elaboration

1. Ask for a specific recent incident, not a description of the value. A question like "tell me about a time the team had to choose between shipping fast and following the documented review process" forces a real story; a question like "how would you describe the engineering culture here" invites a rehearsed, values-page-adjacent answer that tells you little.
2. Check whether the org's structure actually supports the stated value, independent of what anyone says. If a company claims to value psychological safety but every interviewer you meet is visibly guarded about naming any team problem, or if a company claims strong autonomy but every technical decision in the loop turns out to require a director's sign-off, the structural evidence contradicts the claim regardless of the wording used to describe it.
3. Triangulate across multiple people, ideally at different levels and tenures. A single enthusiastic interviewer proves little; a hiring manager, a peer-level engineer, and someone from a different function independently describing the same specific behavior (not the same slogan) is much stronger evidence.
4. Ask what the company would do differently if it stopped believing the value, and watch for a concrete, structural answer versus a vague one. People who work inside a genuinely lived value can usually name a real trade-off it costs them; people describing marketing usually cannot.
5. Treat your own discomfort as data. If a described norm (pace, feedback directness, decision-making style) makes you visibly uneasy during the process itself, that is a more reliable signal about fit than anything printed on the careers page, because it is your own live reaction rather than a claim you are being asked to evaluate secondhand.

Worked example
Suppose a company's careers page says it "empowers engineers with high autonomy." During the loop, ask the hiring manager for a specific recent example: "Tell me about the last time an engineer on this team made a production architecture decision without it going through a review committee first." A genuine, lived-autonomy answer sounds like: "Last quarter one of our engineers decided independently to switch a service from synchronous to async processing after noticing latency complaints; she looped in two people for a sanity check, shipped it, and reported the outcome in the next team sync." A marketing-only answer sounds like: "We really believe in empowering our engineers," repeated with no specific incident when pressed twice. If a peer engineer you speak to separately can also describe a comparable specific incident in their own words, that consistency is strong corroborating evidence; if the hiring manager's story turns out to be the ONLY example anyone can produce company-wide, that is itself informative about how common the behavior actually is.

Trade-offs & pitfalls
The main failure mode is accepting an interviewer's fluent, confident description of the culture as sufficient evidence on its own; confidence and specificity are not the same thing, and a well-rehearsed answer to a values-page question is exactly what a company under-delivering on its stated culture is most likely to have prepared. A second pitfall is over-weighting a single glowing anecdote from one enthusiastic interviewer without checking whether it generalizes; one great story is an anecdote, not a pattern. A third is treating any inconsistency you find as automatically disqualifying: it is normal for a large or growing organization to have real variance across teams, so the useful conclusion is usually about the SPECIFIC team and manager you'd actually join, not the company as a monolithic whole.

Direct answer. Split allocation into size classes (buckets like 32/64/128/256 bytes; every request is rounded up to the bucket above it), give each thread its own cache per class for the lock-free fast path, and fall back to a shared central structure only when a thread's cache is empty (refill) or overfull (flush), moving a batch of blocks per lock acquisition instead of one. Frees always go to the freeing thread's own cache, so a block allocated on one thread and freed on another never needs the original owner; the thread-exit path flushes whatever is left in a dying thread's cache back to the shared structure so nothing is stranded.

Size classes. Round every request up to the nearest class (32, 64, 128, 256 bytes, etc., typically power-of-two or a fixed small ratio apart). This bounds internal fragmentation (space wasted inside an allocated block because it is bigger than what was requested) to the gap between the request and its class (worst case just under 2x for adjacent power-of-two classes, for any request above the smallest class; a 1-byte request in a 32-byte class wastes 31 of its 32 bytes, so the smallest class is where waste per request is highest) while making every free list within a class hold uniformly-sized blocks, so there is no free-list search and no external fragmentation (free space scattered between live blocks, too small or too split up to satisfy a new request) within a class. Requests larger than the biggest class fall back to the system allocator directly; this pool only targets small, frequent objects.

Per-thread cache (fast path). Each thread keeps a private singly-linked free list per size class, stored in thread-local storage (TLS: a separate copy of the variable for every thread, so each thread reads and writes its own without needing a lock), touched with zero locks and zero atomics: allocate pops the head, free (on whichever thread calls it) pushes to the head of that thread's own list for that class. This is the entire point of the design: the overwhelmingly common case touches no shared state at all, so there is no contention (two or more threads trying to use the same lock or shared data at once, which stalls one of them) on the hot path.

Shared central list and batching (slow path). When a thread's cache for a class is empty, it takes one lock on the central structure for that class and pulls a whole batch (for example 32 blocks) in one critical section (the span of code that holds the lock), not one block at a time; when a thread's cache overflows a cap, it pushes a batch back the same way. Batching is what keeps contention low under many threads: the number of lock acquisitions is divided by the batch size, not by the allocation count. The central structure itself gets new memory from the OS in large slabs (a big contiguous chunk of memory, carved up bump-allocated: sequentially handing out the next free address and advancing a pointer, with no free-list bookkeeping needed until the slab itself needs reclaiming) only when both its free list and the current slab are exhausted, so slab acquisition from the OS is rare relative to the allocation rate.

Cross-thread frees. Because every free goes to the freeing thread's cache regardless of which thread originally allocated the block, there is no per-block owner field and no cross-thread signaling needed for the common case. The cost shows up only in aggregate: if one thread (a producer) allocates heavily and another (a consumer) frees everything, the consumer's cache fills past its cap repeatedly and flushes to the central list, while the producer's cache empties repeatedly and refills from the central list; that traffic is bounded by the batch size, not the per-allocation rate, which is exactly what keeps contention from scaling with throughput.

Alternative: send each free back to the block's owner. The design above lets blocks migrate: a block is cached by whichever thread freed it, and returns to the allocating thread only after a flush goes through the central list and a later refill. The main alternative gives every slab (a run of same-size blocks) an owner thread; a free from any other thread pushes the block onto that slab's separate remote-free list with a single atomic compare-and-swap, and the owner drains that list into its private list the next time it needs blocks. mimalloc is built this way (its documentation describes one list per page for the owner's own frees and another for frees from other threads). The trade-off: owner-return keeps blocks next to the slab they came from and needs no central lock for a cross-thread free, but it needs a per-slab owner field, a way to find the slab from a bare pointer (aligned slabs or a page map), an atomic operation on every cross-thread free, and a plan for slabs whose owner has exited or gone idle. The cache-and-batch design above pays a lock only once per batch and tracks no ownership, but it lets memory wander between threads, which can hand two threads blocks that share a cache line (false sharing: two cores writing different variables in the same typically 64-byte line, so the line bounces between them).

Thread-exit reclamation. A thread's cache lives in thread-local storage and has to be flushed when the thread dies: in C++ a thread_local object whose destructor does the flush, in C a destructor registered with pthread_key_create that runs at thread exit. Either one returns every remaining block (in batches) to the shared central structure for each class, so a short-lived thread's leftover cached blocks are not lost to other threads.

Worked example. A minimal version of this design: a thread-local cache with a batch size of 32 and a cap of 64, one mutex-protected central free list that bump-allocates 64 KiB slabs, and a producer thread that allocates 102,400 blocks of 64 bytes and hands them over a 256-slot bounded queue to a consumer thread that frees every one (so every free crosses threads). The consumer also checks each block's marker and index to catch corruption or duplication:

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define BLK 64
#define BATCH 32
#define CAP 64
#define SLAB (64*1024)
#define N 102400
typedef struct node { struct node *next; } node;
static pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER;
static node *central; static char *slab; static size_t used = SLAB; static long locks, slabs;
typedef struct { node *head; int n; } cache;
static __thread cache tc;
static void refill(void){
  pthread_mutex_lock(&mu); locks++;
  for(int i=0;i<BATCH;i++){
    node *b=central;
    if(b) central=b->next;
    else { if(used+BLK>SLAB){ slab=malloc(SLAB); slabs++; used=0; } b=(node*)(slab+used); used+=BLK; }
    b->next=tc.head; tc.head=b; tc.n++;
  }
  pthread_mutex_unlock(&mu);
}
static void flush(void){
  pthread_mutex_lock(&mu); locks++;
  for(int i=0;i<BATCH;i++){ node *b=tc.head; tc.head=b->next; tc.n--; b->next=central; central=b; }
  pthread_mutex_unlock(&mu);
}
static void *palloc(void){ if(!tc.head) refill(); node *b=tc.head; tc.head=b->next; tc.n--; return b; }
static void pfree(void *p){ node *b=p; b->next=tc.head; tc.head=b; tc.n++; if(tc.n>=CAP) flush(); }
/* bounded queue */
#define Q 256
static void *q[Q]; static int qh,qt,qc; static pthread_mutex_t qm=PTHREAD_MUTEX_INITIALIZER; static pthread_cond_t nf=PTHREAD_COND_INITIALIZER, ne=PTHREAD_COND_INITIALIZER;
static void *producer(void *a){ (void)a; for(int i=0;i<N;i++){ unsigned *p=palloc(); p[2]=0xC0FFEE; p[3]=i;
  pthread_mutex_lock(&qm); while(qc==Q) pthread_cond_wait(&nf,&qm); q[qt]=p; qt=(qt+1)%Q; qc++; pthread_cond_signal(&ne); pthread_mutex_unlock(&qm);} return 0; }
static long bad; static char *seen;
static void *consumer(void *a){ (void)a; for(int i=0;i<N;i++){ pthread_mutex_lock(&qm); while(!qc) pthread_cond_wait(&ne,&qm); unsigned *p=q[qh]; qh=(qh+1)%Q; qc--; pthread_cond_signal(&nf); pthread_mutex_unlock(&qm);
  if(p[2]!=0xC0FFEE||p[3]>=N||seen[p[3]]) bad++; else seen[p[3]]=1; pfree(p);} return 0; }
int main(void){ seen=calloc(N,1); pthread_t a,b; pthread_create(&a,0,producer,0); pthread_create(&b,0,consumer,0); pthread_join(a,0); pthread_join(b,0);
 printf("blocks freed on the other thread: %d, corrupted or duplicated: %ld\ncentral lock acquisitions: %ld for %d allocs + %d frees\nslabs of 64 KiB obtained: %ld (no reuse would be %d)\n",N,bad,locks,N,N,slabs,N*BLK/SLAB); return 0; }

Compiled with gcc -O2 -Wall -Wextra -pthread (GCC 14, Linux arm64, in a container) and run five times, it printed the same thing every time:

blocks freed on the other thread: 102400, corrupted or duplicated: 0
central lock acquisitions: 6399 for 102400 allocs + 102400 frees
slabs of 64 KiB obtained: 1 (no reuse would be 100)

The same file also ran with no report under -fsanitize=thread and under -fsanitize=address,undefined. Where 6399 comes from: the producer's cache is empty once per 32 allocations, so 102,400 / 32 = 3,200 refills; the consumer's cache flushes 32 blocks whenever it reaches the cap of 64, which first happens on its 64th free and then once per further 32 frees, so (102,400 - 64) / 32 + 1 = 3,199 flushes (the last blocks stay in its cache below the cap). 3,200 + 3,199 = 6,399 lock acquisitions, one per batch rather than one per operation (204,800 operations, so about 32 operations per lock acquisition). Where the slab count comes from: a 64 KiB slab is 65,536 bytes, so it holds 65,536 / 64 = 1,024 blocks. Without reuse, 102,400 blocks would need 102,400 / 1,024 = 100 slabs (6,553,600 bytes, about 6.25 MiB). With recycling only a handful of blocks are ever outstanding at once: at most 256 in the queue, one in each thread's hand, fewer than 32 in the producer's cache and fewer than 64 in the consumer's, about 350 in total, so the central free list always has something to give back before a new block must be carved and one slab (1,024 blocks) is enough. A larger queue or cache cap raises that peak and the slab count with it.

What this prototype leaves out. It implements one size class (64 bytes) and has no thread-exit flush, so the consumer thread ends holding 32 cached blocks that are never returned to the central list (the producer ends with none, because 102,400 is a multiple of the batch size); the size-class table and the exit-time flush described above are the design, not code the program exercises. Blocks freed on a thread other than the allocator stay in the freeing thread's cache or go to the central list, so slabs are never handed back to the OS here; a real allocator tracks per-slab live counts (or per-slab owners) so a fully free slab can be returned or reused for another size class. Memory carved for one size class also cannot serve another class, which is the main way segregated size classes strand memory between classes.

Hardening for a long-running, security-sensitive process. These add real protection and are extensions layered on top of the per-thread-cache design: guard regions (an unmapped or poisoned page around slabs, or redzone bytes, a sentinel buffer, between blocks) that turn a small overflow into an immediate fault instead of silent corruption; corruption telemetry (a checksum or canary value written into each block's header and checked on free, so a corrupted block is detected and logged rather than silently reused); and zeroing sensitive buffers on free so secret data is not readable in the next object that reuses the same bytes, which costs one memset-sized write per free but closes a real information-disclosure path (freed-but-not-zeroed memory handed to the next consumer, same reuse mechanism that makes allocators fast).

Fragmentation and lifetime-based pooling for mixed workloads. When objects span wildly different lifetimes (some live for one request, some for the whole process), one global allocator still fragments over time because short-lived and long-lived objects interleave in the same slabs. The mitigation is arenas by lifetime: a request-scoped arena (a block of memory handed out in pieces for one logical duration) that is bulk-freed (reset to empty, not walked object by object) at the end of each request, separate from a long-lived arena for objects that outlive requests. This trades per-object free cost (a single arena reset instead of N individual frees) for the restriction that nothing in a request arena can outlive the request.

Trade-offs and pitfalls. The batch size is the key tuning knob: too small and you are back to per-operation lock contention; too large and a thread exiting early strands a large batch that must all be walked and flushed at once. Sized free (the caller must pass the correct size class, as a multi-class version of this design does; the single-class prototype above has no size argument) avoids a per-block header but means a size mismatch between alloc and free is a silent corruption bug with no detection; a production allocator typically adds a debug-mode header check for exactly this reason. Do not conflate this allocator's per-class caches with a general-purpose malloc replacement: size classes above the largest bucket fall straight through to the system allocator, so this design only wins for the common case of many small, similarly-sized objects, which is the case stated in the question.