fix: add id lock to fix map leak

[ningmingxiao]

fixes / addresses containerd/containerd#13561

[marcoabreu]

Independent reproduction, in case it helps this along.

We hit this on Docker hosts where containers carry short-interval HEALTHCHECKs — every healthcheck is a docker exec, so the workload lands squarely on the raced streams.Store / streams.Delete path.

What the data looked like:

• Shim memory tracks cumulative exec count, not container uptime or log volume. A container with a 3s healthcheck interval reached ~96 MB RSS after ~2.05M execs over 71 days; containers with no healthcheck on the same hosts stayed at a ~6 MB baseline after 78 days.
• It is real private heap, not shared-text RSS inflation: smaps_rollup showed PSS 96.2 MB against RSS 98.9 MB, with Anonymous at 95.5 MB. Under genuine memory pressure the kernel reclaimed only ~5 MB of it.
• Not Go's MADV_FREE behaviour — the shims were built with go1.23.7 and go1.25.8.
• Observed on containerd 1.7.27 and 2.2.x.
• Per-exec cost varied roughly 10–50 bytes across hosts, which is consistent with a race whose window depends on CPU speed and load rather than a fixed per-call leak.

The only effective mitigations we found were lengthening the healthcheck interval or dropping the exec-based healthcheck entirely. Restarting dockerd or containerd does not release it, since shims outlive both.

Would be good to see this land.

[ningmingxiao]

ping @fuweid

[ningmingxiao]

ping @mikebrow @mxpv can you take a loook thanks

[mikebrow]

needs rebase

[ningmingxiao]

done thanks @mikebrow

[thaJeztah]

Can you use strconv.Itoa for these (here, and the other places it was added)? Saves some overhead, and will keep linters at bay.

[ningmingxiao]

done @thaJeztah