2019-07-04老师好!FGC正常情况多久一次比较合适啊?我们项目1.2天一次FGC老年代给了3G年轻代1G想吧年轻代给多点。有个定时任务，2小时一次用的线程池。给了40个线程并发请求4K次。设置了空闲回收策略回收核心线程。现在就是定时任务，每次都新建40个线程一张吃老年代内存。不设置回收这些线程不实用的那个吧小时就一直阻塞。怎么处理比较合适作者回复: GC在核心业务应用服务中越久发生越合适，且GC的时间不要太长。一般生产环境的FGC几天一次是比较正常的。40个线程是不是设置太大了，建议调小一些，当然需要你们具体压测验证下调小后的性能情况。
年轻代可以调大一些，如果年轻代太小，当MinorGC时，发现年轻代依然存活满对象，新的对象可能将无法放入到年轻代，则会通过分配担保机制提前转移年轻代的存活对象到老年代中，这样反而会增加老年代的负担。默认情况下老年代和新生代是2:1。建议没有特殊情况，不要固定设置老年代和新生代。 6
2019-07-15老师 Disruptor是不是比ConcurrentLinkedQueue性能更强呢???作者回复: 对的，Disruptor是一款性能更高的有界队列，利用了生产者消费者模式实现，并采用无锁算法、避免伪共享、RingBuffer等优化手段提升该队列框架性能。
3
2019-07-04我有2个问题想请教老师：
1 系统出现问题时我们一般会首先关注资源的使用情况，什么情况下可能是是上下文切换过多导致的呢？CPU消耗过高？
2 ConcurrentLinkedQueue是非阻塞的，是否意味着它会消耗过多的CPu作者回复: CPU消耗过高会引起上下文切换的增加，但并不代表这个就不正常了。正常情况下上下文切换在几百到几千，高峰时段会上升至几万，甚至几十万。
如果上下文长时间处于高位，这个时候我们就要注意了，这种情况有可能是某个线程长期占用CPU，例如之前我提到过的正则表达式出现的严重的回溯问题，就会在某一次回溯时，一直占用CPU，CPU的使用率高居不下，会导致上下文切换激增。
另外一种情况，就是之前你们的业务在高峰值出现的上下文切换在某个值，但是在业务迭代之后，高峰期的上下文切换的值异常高于之前的监控值。比如，我之前说的线程大小调整，导致了高峰期的上下文高出了十几倍之多。
ConcurrentLinkedQueue CAS操作会消耗CPU，但会及时释放，这不足以影响到系统的整体性能。 2
2019-07-04老师，通过vmstat参数获取的参数，可否结合一些真实场景，分析下什么样的数据范围属于正常范围，出现什么样的参数，我们就需要重点关注作者回复: 一般系统出现性能瓶颈，可以结果上下文切换指标进行分析。在之前15讲中，我已经通过一个真实案例讲解了，可以参考下，有什么问题欢迎沟通。
1
2019-09-10打卡+点赞
2019-07-04性能好是一方面，如果是抢购应用在需要用有界队列