成熟的产品环境代码：bounded capacity（受限容量）

Java以前的容器类没有考虑这一点，导致用户可以不停地add元素，这导致内存占用大幅升高，同时也会让服务器无法正常执行，DoS。又如Thread对象，没有考虑周全的话，会很容器new一个新线程去执行，这很容易导致大量线程同时调度执行（由于某种原因它们都没有快速执行完任务干净地退出）

后来的并发类库好了一点，可以有blocking queue，当queue的容量达到预先配置的上限后，添加元素的线程就如进入阻塞状态（或者通过try类的方法返回错误），线程呢，用一个ThreadPoolExecutor线程池来调度task的执行。这样做的好处是：比如说当一个硬件机器的CPU和内存的容量上限通过压力测试知道了之后，可以设置其正常的运行容量为最大上限的80%（high water mark），如果超过了容量限制，可以让后来的task快速失败，同时报个警，这样运营ops就知道需要扩展容量了。

再如Go语言里的Channel，默认是阻塞式的，可用于消息的sender与receiver之间进行同步，也可以指定最大消息个数，从而变成buffering的channel。如果超过缓冲消息数的上限，sender就会收到一个error。

总的来说，就是一个bounded capacity（受限容量）的原则需要体会。不过，这里还有一个小小的问题：这些预先设置的容量上限通常是静态的，则可能无法适应真实业务的计算及数据量需求，最好是自定义动态调整的，但这个具体怎么实施就有点技术含量了：譬如可能会与《控制论》／《排队论》之类的理论有所关联？