• [Java基础]-- Java GC 垃圾回收器的分类和优缺点

    https://blog.csdn.net/high2011/article/details/80177473?utm_source=blogxgwz2

    参考：
    elasticsearch实战-使用G1垃圾回收
    https://donlianli.iteye.com/blog/1948787

    垃圾回收器种类

    http://www.importnew.com/13827.html

    jvm系列(二):JVM内存结构
    https://www.cnblogs.com/ityouknow/p/5610232.html

    jvm系列(三):java GC算法 垃圾收集器
    https://www.cnblogs.com/ityouknow/p/5614961.html

    jvm垃圾回收机制之可达性算法与引用计数算法

     

    在正式回答这个问题之前，先简单说说 Java运行时内存区，划分为线程私有区和线程共享区：

    （1）线程私有区：
    程序计数器，记录正在执行的虚拟机字节码的地址；
    虚拟机栈：方法执行的内存区，每个方法执行时会在虚拟机栈中创建栈帧；
    本地方法栈：虚拟机的Native方法执行的内存区；
    （2）线程共享区：
    Java堆：对象分配内存的区域，这是垃圾回收的主战场；
    方法区：存放类信息、常量、静态变量、编译器编译后的代码等数据，另外还有一个常量池。当然垃圾回收也会在这个区域工作。

    ———————————————分割线 进入正题—————————————————-

    目前虚拟机基本都是采用可达性算法，为什么不采用引用计数算法呢？下面就说说引用计数法是如何统计所有对象的引用计数的，再对比分析可达性算法是如何解决引用技术算法的不足。先简单说说这两个算法：

    引用计数算法（reference-counting） ：每个对象有一个引用计数器，当对象被引用一次则计数器加1，当对象引用失效一次则计数器减1，对于计数器为0的对象意味着是垃圾对象，可以被GC回收。
    可达性算法(GC Roots Tracing)：从GC Roots作为起点开始搜索，那么整个连通图中的对象便都是活对象，对于GC Roots无法到达的对象便成了垃圾回收的对象，随时可被GC回收。
    采用引用计数算法的系统只需在每个实例对象创建之初，通过计数器来记录所有的引用次数即可。而可达性算法，则需要再次GC时，遍历整个GC根节点来判断是否回收。

    下面通过一段代码来对比说明：
    public class GcDemo {

    public static void main(String[] args) {
    //分为6个步骤
    GcObject obj1 = new GcObject(); //Step 1
    GcObject obj2 = new GcObject(); //Step 2

    obj1.instance = obj2; //Step 3
    obj2.instance = obj1; //Step 4

    obj1 = null; //Step 5
    obj2 = null; //Step 6
}

    }

    class GcObject{
    public Object instance = null;
    }

    很多文章以及Java虚拟机相关的书籍，都会告诉你如果采用引用计数算法，上述代码中obj1和obj2指向的对象已经不可能再被访问，彼此互相引用对方导致引用计数都不为0，最终无法被GC回收，而可达性算法能解决这个问题。

    但这些文章和书籍并没有真正从内存角度来阐述这个过程是如何统计的，很多时候大家都在相互借鉴、翻译，却也都没有明白。或者干脆装作讲明白，或者假定读者依然明白。 其实很多人并不明白为什么引用计数法不为0，引用计数到底是如何维护所有对象引用的，可达性是如何可达的？ 接下来结合实例，从Java内存模型以及数学的图论知识角度来说明，希望能让大家彻底明白该过程。

    **

    情况（一）：引用计数算法

    **
    如果采用的是引用计数算法：
    这里写图片描述
    再回到前面代码GcDemo的main方法共分为6个步骤：
    Step1：GcObject实例1的引用计数加1，实例1的引用计数=1；
    Step2：GcObject实例2的引用计数加1，实例2的引用计数=1；
    Step3：GcObject实例2的引用计数再加1，实例2的引用计数=2；
    Step4：GcObject实例1的引用计数再加1，实例1的引用计数=2；
    执行到Step 4，则GcObject实例1和实例2的引用计数都等于2。

    接下来继续结果图：
    这里写图片描述
    Step5：栈帧中obj1不再指向Java堆，GcObject实例1的引用计数减1，结果为1；
    Step6：栈帧中obj2不再指向Java堆，GcObject实例2的引用计数减1，结果为1。
    到此，发现GcObject实例1和实例2的计数引用都不为0，那么如果采用的引用计数算法的话，那么这两个实例所占的内存将得不到释放，这便产生了内存泄露。

    情况（二）：可达性算法

    这是目前主流的虚拟机都是采用GC Roots Tracing算法，比如Sun的Hotspot虚拟机便是采用该算法。 该算法的核心算法是从GC Roots对象作为起始点，利用数学中图论知识，图中可达对象便是存活对象，而不可达对象则是需要回收的垃圾内存。这里涉及两个概念，一是GC Roots，一是可达性。

    下面详细介绍可达性算法：

    这个算法的基本思路就是通过一系列的称谓“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所有走过的路径为引用链，当一个对象到GC Roots没有任何引用链项链时，则证明此对象时不可用的，下面看一下例子：

    这里写图片描述

    上面的这张图，对象object5、object6、object7虽然互相没有关联，但是它们到GC Roots是不可达的，所以它们将会被判定为是可回收的对象
    注：Java语言中，可作为GC Roots的对象包括下面几种：
    1) 虚拟机栈(栈帧中的本地变量表)中引用的对象
    2) 方法区中类静态属性引用的对象
    3) 方法区中常量引用的对象
    4) 本地方法栈中JNI(即一般说的Native方法)引用的对象

    二、Java中的引用类型
    从JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用，软引用，弱引用，虚引用，这四种引用的强度一次逐渐减弱
    1) 强引用就是指在程序代码之中普遍存在的，类似 “Object obj = new Object()” 这类的引用，只要强引用还存在，垃圾回收器永远不会回收掉被引用的对象。
    2) 软引用是用来描述一些还有用但并非需要的对象，对于软引用关联着的对象，在系统将要发生内存异常之前，将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存异常
    3) 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存岛下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存释放足够，都会回收掉只被弱引用关联的对象
    4) 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例，对一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知

    java引用可以参考：http://www.cnblogs.com/zedosu/p/6632249.html

    三、垃圾收集算法
    1) 标记-清除算法
    最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象，它的标记过程其实在前一节讲述对象标记判定时已经基本介绍过了。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。 标记-清除算法的执行过程如图

    这里写图片描述

    2) 复制算法
    为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，未免太高了一点。复制算法的执行过程如图

    这里写图片描述

    3) 标记-整理算法
    复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。
    根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如图

    这里写图片描述

    4) 分代收集算法
    当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收

    四、Java虚拟机对堆的内存细化的几个区域，并且这些区域都是采用哪些收集算法。

    这里写图片描述

    JVM内存模型中分两大块，一块是New Generation, 另一块是Old Generation. 在New Generation中，有一个叫Eden的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to）, 它们用来存放每次垃圾回收后存活下来的对象。在Old Generation中，主要存放应用程序中生命周期长的内存对象，还有个Permanent Generation，主要用来放JVM自己的反射对象，比如类对象和方法对象等。
    1) 在New Generation块中，垃圾回收一般用复制算法，速度快。每次GC的时候，存活下来的对象首先由Eden拷贝到某个Survivor Space, 当Survivor Space空间满了后, 剩下的live对象就被直接拷贝到Old Generation中去。因此，每次GC后，Eden内存块会被清空
    2) 在Old Generation块中，垃圾回收一般用标记整理的算法，速度慢些，但减少内存要求.

    垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收Old段中的垃圾；1级或以上为部分垃圾回收，只会回收New中的垃圾，内存溢出通常发生于Old段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。

    Out Of Memory 只发生在jvm对old和perm generation 回收后还不能获足够内存的情况.
    当生成一个新对象时，内存申请过程如下：
    A. JVM会试图为相关Java对象在Eden中初始化一块内存区域
    B. 当Eden空间足够时，内存申请结束。否则到下一步
    C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区
    D. Survivor区被用来作为Eden及Old的中间交换区域，当Old区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区
    E. 当Old区空间不够时，JVM会在Old区进行完全的垃圾收集（0级）
    F. 完全垃圾收集后，若Survivor及Old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory错误”

    造成full gc的原因
    new了很多对象,没有即时在主动释放掉->Eden内存不够用->不断把对象往old迁移->old满了->full gc
    总结：上面的内容就介绍了Java虚拟机如何管理对象的，我们也看到了上面主要就是收集算法和堆空间的从新划分，这样做的目的都是在于垃圾回收的高效执行，但是总归看来，如果对象交给系统来管理，在系统运行的过程效率肯定会有影响的，但是这有一点比较好，就是不需要手动管理，给程序猿带来方便。

    参考：https://www.zhihu.com/question/21539353/answer/18596488
    参考：http://blog.csdn.net/jiangwei0910410003/article/details/40709457

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 

    所属专栏： Java
     
     版权声明：尊重原创，转载请标明,本文转自 https://blog.csdn.net/high2011/article/details/80177473

    关于Java的垃圾回收器，一直是个头疼的问题，这里简要说明下分类和优缺点，供选择使用。

    一、JVM GC 垃圾回收器类型

    JVM的垃圾回收器大致分为六种类型：

    1、串行：垃圾回收器 (Serial Garbage Collector)

    (1)串行垃圾回收器在进行垃圾回收时，它会停止应用程序的所有线程，使用单个垃圾回收线程来进行垃圾回收工作。

    串行垃圾回收器是为单线程环境而设计的，如果你的程序不需要多线程，启动串行垃圾回收。

    (2)串行收集器是最古老，最稳定以及效率高的收集器，可能会产生较长的停顿，只使用一个线程去回收。新生代、老年代使用串行回收；新生代复制算法、老年代标记-压缩；垃圾收集的过程中会Stop The World（服务暂停）

    使用方法：-XX:+UseSerialGC  串联收集

    Ps：在jdk client模式，不指定VM参数，默认是串行垃圾回收器

    2、串行：ParNew收集器
    ParNew收集器其实就是Serial收集器的多线程版本。新生代并行，老年代串行；新生代复制算法、老年代标记-压缩
    使用方法：-XX:+UseParNewGC  ParNew收集器
                    -XX:ParallelGCThreads 限制线程数量

    3、并行：Parallel收集器
    Parallel Scavenge收集器类似ParNew收集器，Parallel收集器更关注系统的吞吐量。可以通过参数来打开自适应调节策略，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量；也可以通过参数控制GC的时间不大于多少毫秒或者比例；新生代复制算法、老年代标记-压缩
    使用方法：-XX:+UseParallelGC  使用Parallel收集器+ 老年代串行   

    4、并行：Parallel Old 收集器
    Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在JDK 1.6中才开始提供
    使用方法： -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代并行

    5、并发标记扫描CMS收集器

    CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用都集中在互联网站或B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。

    java官方介绍：https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html

    从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于“标记-清除”算法实现的，它的运作过程相对于前面几种收集器来说要更复杂一些，整个过程分为4个步骤，包括：
    初始标记（CMS initial mark）
    并发标记（CMS concurrent mark）
    重新标记（CMS remark）
    并发清除（CMS concurrent sweep）
    其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
    由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行。老年代收集器（新生代使用ParNew）

      优点:并发收集、低停顿
      缺点：产生大量空间碎片、并发阶段会降低吞吐量

     使用方法：

    -XX:+UseConcMarkSweepGC  使用CMS收集器

    -XX:+ UseCMSCompactAtFullCollection Full GC后，进行一次碎片整理；整理过程是独占的，会引起停顿时间变长
    -XX:+CMSFullGCsBeforeCompaction  设置进行几次Full GC后，进行一次碎片整理
    -XX:ParallelCMSThreads  设定CMS的线程数量（一般情况约等于可用CPU数量） 

    举例：

    6、G1收集器
    G1是目前技术发展的最前沿成果之一，HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。与CMS收集器相比G1收集器有以下特点：
    (1). 空间整合，G1收集器采用标记整理算法，不会产生内存空间碎片。分配大对象时不会因为无法找到连续空间而提前触发下一次GC。
    (2). 可预测停顿，这是G1的另一大优势，降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为N毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。
    上面提到的垃圾收集器，收集的范围都是整个新生代或者老年代，而G1不再是这样。使用G1收集器时，Java堆的内存布局与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔阂了，它们都是一部分（可以不连续）Region的集合。
    G1的新生代收集跟ParNew类似，当新生代占用达到一定比例的时候，开始出发收集。和CMS类似，G1收集器收集老年代对象会有短暂停顿。
    收集步骤：
    1)、标记阶段，首先初始标记(Initial-Mark),这个阶段是停顿的(Stop the World Event)，并且会触发一次普通Mintor GC。对应GC log:GC pause (young) (inital-mark)
    2)、Root Region Scanning，程序运行过程中会回收survivor区(存活到老年代)，这一过程必须在young GC之前完成。
    3)、Concurrent Marking，在整个堆中进行并发标记(和应用程序并发执行)，此过程可能被young GC中断。在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收(图中打X)。同时，并发标记过程中，会计算每个区域的对象活性(区域中存活对象的比例)。
    4)、Remark, 再标记，会有短暂停顿(STW)。再标记阶段是用来收集 并发标记阶段 产生新的垃圾(并发阶段和应用程序一同运行)；G1中采用了比CMS更快的初始快照算法:snapshot-at-the-beginning (SATB)。
    5)、Copy/Clean up，多线程清除失活对象，会有STW。G1将回收区域的存活对象拷贝到新区域，清除Remember Sets，并发清空回收区域并把它返回到空闲区域链表中。
    6)、复制/清除过程后。回收区域的活性对象已经被集中回收到深蓝色和深绿色区域。
    唯一和串行垃圾回收器不同的是，并行垃圾回收器是使用多线程来进行垃圾回收工作的。

    java8中，使用方法： -XX:+UseStringDeduplication

    默认：-XX:+UseG1GC

    二、垃圾回收器的选用决定因素：

    1、应用程序的场景
    2、硬件的制约
    3、吞吐量的需求

    串行垃圾回收是最简单的也是效率最低的，如果只是控制台的单线程程序，简单任务，并且机器配置不高，推荐使用。

    并行垃圾回收器是64bit server默认的垃圾回收器，一般我们工作和生产上默认不配置，都是并行垃圾回收。对于一般的不要求吞吐的应用，并且硬件资源不是太充足的情况下，并行垃圾回收器差不多能满足需求。

    CMS垃圾回收器是对并行垃圾回收器的一个优化，它以CPU和系统资源为代价，换取GC的延迟。不会一GC就STW，而是根据情况STW。一定程度上是资源换取速度。

    G1垃圾回收器是针对于大heap的垃圾回收器，如果heap分配的足够大，分的region的优先级回收策略会优先清理垃圾多的region.并且减少了内存空间碎片，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

    三、配置

    OptionDescription
    -XX:+UseSerialGC Serial Garbage Collector 串行垃圾回收器
    -XX:+UseParallelGC Parallel Garbage Collector并行垃圾回收器
    -XX:+UseConcMarkSweepGC CMS Garbage Collector并发标记垃圾回收器
    -XX:ParallelCMSThreads= CMS Collector – number of threads to use 并发标记垃圾回收器使用的线程数，通常是cpu个数
    -XX:+UseG1GC G1 Gargbage Collector 使用G1垃圾回收器

    GC Optimization Options

    OptionDescription
    -Xms Initial heap memory size 初始化heap大小 -Xms512M
    -Xmx Maximum heap memory size 设置最大的heap大小
    -Xmn Size of Young Generation 年轻代的大小
    -XX:PermSize Initial Permanent Generation size 初始化永久带的大小
    -XX:MaxPermSize Maximum Permanent Generation size 最大的永久带大小


    Parallel GC 并行垃圾回收策略举例：

    java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC MaxGCPauseMillis=100 -XX:MaxGCPauseMillis=100

    CMS GC 并发标记清楚垃圾回收策略举例：

    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k-XX:ParallelGCThreads=20  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection

    Eg：

    java -Xmx12m -Xms3m -Xmn1m -XX:PermSize=20m -XX:MaxPermSize=20m -XX:+UseSerialGC -jar java-application.jar

    更多详细配置，请参考：http://blog.sina.com.cn/s/blog_4080505a0101i6cr.html

    四、查看垃圾回收器

    我们知道jvm分client 和 server模式。

    如果启动jvm不指定模式，jdk会根据当前的操作系统配置来启动不同模式的jvm。

    默认64bit操作系统下都会是server模式的jvm。

    java -XX: +PrintCommandLineFlags -version
    1.  
      [root@bdasfadsfds ~]# java -XX:+PrintCommandLineFlags -version
    2.  
      -XX:InitialHeapSize=2111804480 -XX:MaxHeapSize=32210157568 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
    3.  
      java version "1.8.0_45"
    4.  
      Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
    5.  
      Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

    五、小结

    • 垃圾回收器目前分为6种类型, 串行，并行，并发标记，G1。
    • 小数据量和小型应用，使用串行垃圾回收器即可。
    • 对于对响应时间无特殊要求的，可以使用并行垃圾回收器和并发标记垃圾回收器。（中大型应用）
    • 对于heap可以分配很大的中大型应用，使用G1垃圾回收器比较好，进一步优化和减少了GC暂停时间。
    •  没有银弹，针对不同的场景，选用不同的垃圾回收器。

    六、流行的组合

    • Serial
    • ParNew + CMS
    • ParallelYoung + ParallelOld
    • G1GC

    七、图像

    参考：

    1. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html
    2. http://javapapers.com/java/types-of-java-garbage-collectors/
    3. http://blog.sina.com.cn/s/blog_4080505a0101i6cr.html
    4. http://www.techpaste.com/2012/02/20/default-jvm-settings-gc-jit-java-heap-sizes-xms-xmx-operating-systems/#more-3569
    5. http://docs.oracle.com/javase/1.5.0/docs/guide/vm/server-class.html
    6. https://blog.csdn.net/oopsoom/article/details/40374897
    7. http://www.importnew.com/23752.html
    8. https://javapapers.com/java/types-of-java-garbage-collectors/
    9. https://my.oschina.net/hosee/blog/644618
    10. http://xinklabi.iteye.com/blog/1767666
    11. http://blog.51cto.com/sunbean/768034
  • 相关阅读:
    【leetcode】Maximum Subarray
    【USACO】
    【leetcode】Remove Duplicates from Sorted Array
    【leetcode】Path Sum II
    【leetcode】Swap Nodes in Pairs
    【leetcode】Word Ladder
    【leetcode】Copy List with Random Pointer
    【leetcode】Longest Palindromic Substring
    #ifdef #endif #if #endif
    tar [options] [list of file]
  • 原文地址：https://www.cnblogs.com/kelelipeng/p/10738223.html
Copyright © 2020-2023  润新知