刷题心得（1）

抽象类与接口的区别

比较	抽象类	接口
默认方法	有默认的方法可以实现	1.8之前，接口不存在方法的实现
实现方式	实现抽象类使用extends关键字来继承抽象类。如果子类不是抽象类的话，它需要提供抽象类中所有声明的方法的实现。	子类使用关键字implements来实现接口。它需要提供接口中所有声明的方法的实现
构造器	有	无
与正常类的区别	不能被实例化	不同的类型
访问权限修饰	public、protected和default	public
多继承	一个子类存在一个父类	一个子类可以存在多个接口
添加新方法	抽象类中添加新方法，可以提供默认的实现不用修改子类的代码	接口中添加新方法，子类需要实现改方法
方法体	抽象方法不能有方法体，子类可以不覆写父类的抽象方法，但子类也要申明为抽象类；子类可以选择覆写父类的非抽象方法

例子
在JDK1.8之前的版本（不包括JDK1.8），接口中不能有静态方法，抽象类中因为有普通方法，故也可以有
静态方法。
在JDK1.8后（包括JDK1.8），在抽象类中依旧可以有静态方法，同时在接口中也可以定义静态方法了。
以下代码在JDK1.8之后是没有问题的（可以通过接口名来调用静态方法 ：Main.prinf(); ）：

public interface Demo{
    public static void print() {         
      System.out.println("Hello World!");      }
}

PS：
在JDK1.7，接口中只包含抽象方法，使用public abstract 修饰。

public interface Demo{
    public abstract void method();
}

在JDK1.8，接口中新加了默认方法和静态方法：
默认方法：使用default修饰，在接口的实现类中，可以直接调用该方法，也可以重写该方法。
静态方法：使用static修饰，通过接口直接调用。

public interface Demo{
    //默认方法
    public default void method(){
        System.out.println("default method...");
    }
 
    //静态方法
    public static void print(){
        System.out.println("static method...");
    }
}

在JDK1.9，接口中新加了私有方法，使用private修饰，私有方法供接口内的默认方法调用。
复制代码

public interface Demo{
    private void method() {
        System.out.println("Hello World!");
    }
}

JVM垃圾回收机制

1、在java中，对象的内存在哪个时刻回收，取决于垃圾回收器何时运行。
2、一旦垃圾回收器准备好释放对象占用的存储空间，将首先调用其finalize()方法， 并且在下一次垃圾回收动作发生时，才会真正的回收对象占用的内存（《java 编程思想》）
3、在C++中，对象的内存在哪个时刻被回收，是可以确定的，在C++中，析构函数和资源的释放息息相关，能不能正确处理析构函数，关乎能否正确回收对象内存资源。在java中，对象的内存在哪个时刻回收，取决于垃圾回收器何时运行，在java中，所有的对象，包括对象中包含的其他对象，它们所占的内存的回收都依靠垃圾回收器，因此不需要一个函数如C++析构函数那样来做必要的垃圾回收工作。当然存在本地方法时需要finalize()方法来清理本地对象。在《java编程思想》中提及，finalize()方法的一个作用是用来回收“本地方法”中的本地对象
4、线程的释放是在run()方法结束以后，此时线程的引用可能并未释放

详解

垃圾回收包含的内容不少，但顺着下面的顺序捋清知识也并不难。首先要搞清垃圾回收的范围（栈需要GC去回收吗？），然后就是回收的前提条件如何判断一个对象已经可以被回收（这里只重点学习根搜索算法就行了），之后便是建立在根搜索基础上的三种回收策略，最后便是JVM中对这三种策略的具体实现。

1. 范围：要回收哪些区域？

Java方法栈、本地方法栈以及PC计数器随方法或线程的结束而自然被回收，所以这些区域不需要考虑回收问题。Java堆和方法区是GC回收的重点区域，因为一个接口的多个实现类需要的内存不一样，一个方法的多个分支需要的内存可能也不一样，而这两个区域又对立于栈可能随时都会有对象不再被引用，因此这部分内存的分配和回收都是动态的。

2. 前提：如何判断对象已死？
   （1）引用计数法
   引用计数法就是通过一个计数器记录该对象被引用的次数，方法简单高效，但是解决不了循环引用的问题。比如对象A包含指向对象B的引用，对象B也包含指向对象A的引用，但没有引用指向A和B，这时当前回收如果采用的是引用计数法，那么对象A和B的被引用次数都为1，都不会被回收。
   下面是循环引用的例子，在Hotspot JVM下可以被正常回收，可以证实JVM
   采用的不是简单的引用计数法。通过-XX:+PrintGCDetails输出GC日志。

public class ReferenceCount {  
    final static int MB = 1024 * 1024;  
    byte[] size = new byte[2 * MB];  
    Object ref;  

      

    public static void main(String[] args) {  

        ReferenceCount objA = new ReferenceCount();  

        ReferenceCount objB = new ReferenceCount();  

        objA.ref = objB;  

        objB.ref = objA;  

          

        objA = null;  

        objB = null;  

          

        System.gc();  

        System.gc();  

    }  

  

}  

（2）根搜索
通过选取一些根对象作为起始点，开始向下搜索，如果一个对象到根对象不可达时，则说明此对象已经没有被引用，是可以被回收的。可以作为根的对象有：栈中变量引用的对象，类静态属性引用的对象，常量引用的对象等。因为每个线程都有一个栈，所以我们需要选取多个根对象。
附：对象复活
在根搜索中得到的不可达对象并不是立即就被标记成可回收的，而是先进行一次标记放入F-Queue等待执行对象的finalize()方法，执行后GC将进行二次标记，复活的对象之后将不会被回收。因此，使对象复活的唯一办法就是重写finalize()方法，并使对象重新被引用。

public class DeadToRebirth {  

  

    private static DeadToRebirth hook;   

      

    @Override  

    public void finalize() throws Throwable {  

        super.finalize();  

        DeadToRebirth.hook = this;  

    }  

      

    public static void main(String[] args) throws Exception {  

        DeadToRebirth.hook = new DeadToRebirth();  

        DeadToRebirth.hook = null;  

        System.gc();  

        Thread.sleep(500);  

        if (DeadToRebirth.hook != null)  

            System.out.println("Rebirth!");  

        else  

            System.out.println("Dead!");  

          

        DeadToRebirth.hook = null;  

        System.gc();  

        Thread.sleep(500);  

        if (DeadToRebirth.hook != null)  

            System.out.println("Rebirth!");  

        else  

            System.out.println("Dead!");  

    }  

      

}  

要注意的两点是：

第一，finalize()方法只会被执行一次，所以对象只有一次复活的机会。

第二，执行GC后，要停顿半秒等待优先级很低的finalize()执行完毕。

3. 策略：垃圾回收的算法
   （1）标记-清除

前面两种策略的缺点很明显，回收后内存碎片很多，如果之后程序运行时申请大内存，可能会又导致一次GC。虽然缺点明显，这种策略却是后两种策略的基础。正因为它的缺点，所以促成了后两种策略的产生。

（2）标记-复制

将内存分为两块，标记完成开始回收时，将一块内存中保留的对象全部复制到另一块空闲内存中。实现起来也很简单，当大部分对象都被回收时这种策略也很高效。但这种策略也有缺点，可用内存变为一半了！

为什么不是全部呢？如果回收时，空闲的那一小块Survivor不够用了怎么办？这就是老年代的用处。当不够用时，这些对象将直接通过分配担保机制进入老年代。那么老年代也使用标记-复制策略吧？当然不行！老年代中的对象可不像新生代中的，每次回收都会清除掉大部分。如果贸然采用复制的策略，老年代的回收效率可想而知。

（3）标记-整理

根据老年代的特点，采用回收掉垃圾对象后对内存进行整理的策略再合适不过，将所有存活下来的对象都向一端移动。

4. 实现：虚拟机中的收集器

（1）新生代上的GC实现

Serial：单线程的收集器，只使用一个线程进行收集，并且收集时会暂停其他所有工作线程（Stop the world）。它是Client模式下的默认新生代收集器。

ParNew：Serial收集器的多线程版本。在单CPU甚至两个CPU的环境下，由于线程交互的开销，无法保证性能超越Serial收集器。

Parallel Scavenge：也是多线程收集器，与ParNew的区别是，它是吞吐量优先收集器。吞吐量=运行用户代码时间/(运行用户代码+垃圾收集时间)。另一点区别是配置-XX:+UseAdaptiveSizePolicy后，虚拟机会自动调整Eden/Survivor等参数来提供用户所需的吞吐量。我们需要配置的就是内存大小-Xmx和吞吐量GCTimeRatio。

（2）老年代上的GC实现

Serial Old：Serial收集器的老年代版本。

Parallel Old：Parallel Scavenge的老年代版本。此前，如果新生代采用PS GC的话，

老年代只有Serial Old能与之配合。现在有了Parallel Old与之配合，可以在注重吞吐量

及CPU资源敏感的场合使用了。

CMS：采用的是标记-清除而非标记-整理，是一款并发低停顿的收集器。但是由于

采用标记-清除，内存碎片问题不可避免。可以使用-XX:CMSFullGCsBeforeCompaction

设置执行几次CMS回收后，跟着来一次内存碎片整理。

5. 触发：何时开始GC？

Minor GC（新生代回收）的触发条件比较简单，Eden空间不足就开始进行Minor GC回收新生代。而Full GC（老年代回收，一般伴随一次Minor GC）则有几种触发条件：

• 老年代空间不足

• PermSpace空间不足

• 统计得到的Minor GC晋升到老年代的平均大小大于老年代的剩余空间

这里注意一点：PermSpace并不等同于方法区，只不过是Hotspot JVM用PermSpace来实现方法区而已，有些虚拟机没有PermSpace而用其他机制来实现方法区。

6.补充：对象的空间分配和晋升

（1）对象优先在Eden上分配

（2）大对象直接进入老年代

虚拟机提供了-XX:PretenureSizeThreshold参数，大于这个参数值的对象将直接分配到

老年代中。因为新生代采用的是标记-复制策略，在Eden中分配大对象将会导致Eden区

和两个Survivor区之间大量的内存拷贝。

（3）长期存活的对象将进入老年代

对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度

（默认为15岁）时，就会晋升到老年代中。

多线程与锁

一个是run和start区别，Thread.run()是调用方法，Thread. start()是启动线程；

另一个是锁持有问题。这个题是调用方法，和多线程就无关。本题只有一个线程，持有HelloSogou.class

锁。那么，就是另一个问题：同步方法调用另一个同步方法的锁问题？

public synchronized void methodA(int a, int b){}
public synchronized void methodB(int a）{
     methodA(a, 0);
}

首先要明白两个问题，1.锁的对象是谁？2.谁持有了锁？

第一点是run与start方法区别，调用run时只是单纯执行方法，故按代码顺序执行下来结果就是SogouHello。

接着我们再来看看把run换成start，结果是HelloSogou，这是为什么呢。

首先调用start是开始了一个线程，那么现在程序中有了两个线程主线程main和线程T。

这就涉及本题第二个知识点了，函数使用的锁是this(即对象本身)，若函数被static修饰则锁为 类

名.class.

那么题目中两个函数都是使用了同一个锁即HelloSogou.class，当执行t.start时，t线程准备调用Sogou

方法，但是锁对象已被主线程占用，故要等待主线程执行完System.out.print(“Hello”)后释放锁才可以

执行自己的Sogou方法。故此结果是HelloSogou