Semaphore fair mode versus non-fair mode for throttling alert dispatch
0 reputation · 26 Mar 2026, 15:43 UTC
Goal: use java.util.concurrent.Semaphore(int permits, boolean fair) to bound concurrent alert dispatches on Java 5+ and select a fairness policy.
With fair=true, permits are handed to waiting threads in approximately FIFO wait order, which can smooth delivery and reduce burst noise, at the cost of AQS queue management and unparking overhead that may raise tail latency. With fair=false, the default, new arrivals may bypass waiters, improving throughput but risking bursts and starvation. The JDK treats fairness as a scheduling hint, not a strict FIFO contract, so exact dispatch order depends on the JVM and OS scheduler. The Semaphore bounds only in-flight count; it does not deduplicate alerts or enforce per-window rates.
Does fair mode measurably reduce alert burst noise compared with non-fair mode under sustained contention? Is the possible tail-latency increase acceptable when even delivery matters more than maximum throughput? Should a separate deduplication or rate-limiting layer be added if the goal is noise suppression rather than concurrency bounding?