public String substring(int beginIndex, int endIndex) {
if (beginIndex < 0) {
throw new StringIndexOutOfBoundsException(beginIndex);
if (endIndex > value.length) {
throw new StringIndexOutOfBoundsException(endIndex);
int subLen = endIndex - beginIndex;
if (subLen < 0) {
throw new StringIndexOutOfBoundsException(subLen);
return ((beginIndex == 0) && (endIndex == value.length)) ? this
: new String(value, beginIndex, subLen);
public String(char value[], int offset, int count) {
if (offset < 0) {
throw new StringIndexOutOfBoundsException(offset);
if (count <= 0) {
if (count < 0) {
throw new StringIndexOutOfBoundsException(count);
if (offset <= value.length) {
this.value = "".value;
return;
if (offset > value.length - count) {
throw new StringIndexOutOfBoundsException(offset + count);
this.value = Arrays.copyOfRange(value, offset, offset+count);
public static char[] copyOfRange(char[] original, int from, int to) {
int newLength = to - from;
if (newLength < 0)
throw new IllegalArgumentException(from + " > " + to);
char[] copy = new char[newLength];
System.arraycopy(original, from, copy, 0,
Math.min(original.length - from, newLength));
return copy;
char[] copy = new char[newLength]
是的，在JDK1.7中，切割出来的每一个字符串都会创建一个新的char[]对象，而我们项目用的就是JDK1.7
那么，按照上述的数据量，则创建的新对象总数有：66w * 5 = 330w，一个巨量级，可怕！
那么我们来验证一下吧，把这个线程中有关String.split()的代码去掉吧，部署上去，观察结果如下：
Full GC现在变为每隔6分钟执行一次了，虽然情况仍然很糟，但是至少有所改善，String.split()确实是一个原因所在。
所以唯一的办法就是重构这段逻辑。
文章目录惨案的发生解决方案后续分析可怕的String.split()总结惨案的发生Full GC很正常，但是频繁的Full GC并且导致线上CPU飙升，然后服务直接宕掉，这是很可怕的。2018年11月19号，项目升级，起初观察日志都OK，但是半小时后，服务无法访问，界面无法打开（最初是Zabbix监控CPU飙升，然后邮件告警才知道）。然后拜托性能测试的同事帮忙一起分析问题，首先是线上Ful...
JVM频繁Full GC导致服务不可用定位过程 背景：问题描述：JVM启动参数配置：Jstat 实时监控真相逐渐浮现jstat 分析gc原因：使用mat辅助分析定位哪里引用了groovy导致内存泄漏查看ShardingJDBC发版记录写在最后
公司推行微服务策略，我负责的XX模块相对于其他业务来讲相对独立，所以作为微服务推行的试点。于是
分析业务边界 ；
做相关的架构升级：
从Spri...
问题描述最近公司的线上监控系统给我推送了一些kafka lag持续增长的消息，我上生产环境去看了相应的consumer的情况，发现几台机器虽然还在处理消息，但是速度明显慢了很多。问题猜测与验证我猜测是JVM频繁做Full GC，导致进程也跟着频繁卡顿，处理消息的速度自然就慢了。为了验证这个想法，先用jstat看看内存使用情况：
jstat -gcutil 1 1000 #1是进程号
结果如我所
在Java虚拟机中，垃圾收集器主要分为三种类型：Minor GC（新生代垃圾收集）、Major GC（老年代垃圾收集）和Full GC（整堆垃圾收集）。
1. Minor GC：Minor GC 也称为新生代垃圾收集。它是指对新生代进行垃圾回收的过程。当新生代内存空间使用完毕时，就需要进行垃圾回收。Minor GC 主要回收年轻代，包括Eden区和Survivor区。在 Minor GC 的过程中，对于那些无法被回收的对象，会被直接送到老年代中。
2. Major GC：Major GC 也称为老年代垃圾收集。它主要是对老年代进行垃圾回收，当老年代内存空间不足时，就需要进行垃圾回收。Major GC 的执行频率比 Minor GC 低，对系统性能影响也比较大。被回收的对象可以是从新生代晋升到老年代的对象，也可以是老年代中的对象。
3. Full GC：Full GC 也称为整堆垃圾收集，顾名思义，就是对整个堆空间进行垃圾回收。Full GC 通常是在老年代内存不足时触发。Full GC 的执行会导致应用程序停顿，对系统性能影响最大。
总的来说，Minor GC 主要针对新生代进行垃圾回收，Major GC 主要针对老年代进行垃圾回收，而 Full GC 则是对整个堆空间进行垃圾回收，包括新生代和老年代。不同的垃圾收集器对这些垃圾回收的过程和策略可能会有所不同。
<mirrorOf>*</mirrorOf>
<!--该镜像的URL。构建系统会优先考虑使用该URL，而非使用默认的服务器URL。 -->
<url>http://174.12.8.50:8081/nexus/repository/maven-public/</url>
</mirror>
</mirrors>
[/code]
