CMS（Concurrent Mark Sweep）是HotSpot虚拟机中第一款实现并发收集的垃圾回收器，是为那些希望使用较短的垃圾收集暂停时间并且可以在应用程序运行时与垃圾收集器共享处理器资源的应用程序而设计的，简单来说，CMS就是追求最短停顿时间的垃圾收集器。CMS主要针对老年代进行垃圾回收，可以配合Serial或者ParNew新生代垃圾收集器进行回收，并且从名字上包含“Mark Sweep

1、直接停掉服务器

今天遇到有同事在使用fastjson的JSONObject时，直接在parse方法中传入了一个非json格式的字符串，造成有时候报错，有时候又能正常返回。问题现象当你传入一个数值类型时，可以正常解析，当你传入一个非数值类型时，解析就报错了。public class TestJson {public static void main(String[] args) {Object parse = JS

分区分配指的是Kafka依据什么样的分配方式将多个主题中的多个分区与多个消费者进行对应。Range按范围分配。对于每个主题，我们按数字顺序排列可用分区，并按字典顺序排列消费者。然后，我们将分区数除以消费者总数，以确定要分配给每个消费者的分区数。如果它不能平均分配，那么前几个消费者将会有一个额外的分区。partition数/consumer数比如现在有两个消费者C0 ，C1两个主题t0 ，t1每个主

我们都知道Kafka一大特点就是快，每秒甚至可以达到百万级别的吞吐量，然后这种级别的吞吐量居然还是基于磁盘的读写，那么kafka是如何做到的呢？接下来我们就一起来分析下其中的奥妙。磁盘顺序写对于一般的机械硬盘来说如果要查找某个数据，需要先寻址，然后通过机械运动（磁头臂驱动磁头找到对于的磁道、扇面）来读取数据，这种飘忽不定的查询方式就造成了大量的时间消耗在了机械运动上，磁头被不停的移来移去，所以说我

我们知道Kafka对于消息的可靠性可以做到至少一次（at least once）的保证，即消息不会丢失，但有可能重复发送，本文就来分析一下Kafka究竟是如何做到的。可以看出，要想确保Kafka消息不丢失，Consumer、Producer以及Broker都需要做好各自所负责的部分，Producer需要确保消息成功发送到Broker端，Broker端则要确保消息的成功落盘、多副本、持久化，Cons

Kafka核心功能概念

kafka生产者为我们提供了三种发送消息的方式。

使用，可以保证消息的顺序性，假设有两条消息A、B，A先发送但失败了在执行重试时，B发送且成功了，之后A也重试成功了，此时A、B消息顺序就反了，如果将此参数设置为1，则可以保证A在重试时，B消息无法进行发送，必须等A收到broker响应后B才能发送，设置较高可以提升吞吐量，但会占用更多的内存，此参数值。这有助于提高客户端和服务器的性能。设置请求消息的最大大小，避免发送大量的请求，限制了单条消息的si

batch.size当多条消息发送到batch后，batch的上限大小（字节为单位），当达到上限时则会发送给kafka broker，设置的过小则降低了kafka的吞吐量，设置的过大则消息的延迟时间会拉长、占用了过高的内存...