下面是一个围绕Java 8的解释，试图展示抽象类和接口之间的关键区别，并涵盖Java助理考试所需的所有细节。

关键概念:

一个类只能扩展一个类，但它可以实现任意数量的接口 接口定义了类的功能，抽象类定义了它是什么 抽象类是类。它们不能被实例化，但在其他方面表现得像普通类 两者都可以有抽象方法和静态方法 接口可以有默认方法和静态final常量，也可以扩展其他接口 所有接口成员都是公共的(直到Java 9)

接口定义了类的功能，抽象类定义了它是什么

每罗迪格林：

接口通常用来描述一个类的能力，而不是它的中心标识，例如，一个Automobile类可能实现了可回收接口，它可以应用于许多不相关的对象。抽象类定义其后代的核心标识。如果你定义一个Dog抽象类，那么达尔马提亚的后代就是Dog，他们不仅仅是可狗的。

Pre Java 8， @Daniel Lerps的回答非常准确，接口就像实现类必须履行的契约。

现在，使用默认方法，它们更像一个Mixin，仍然执行契约，但也可以提供代码来完成这项工作。这使得接口可以接管抽象类的一些用例。

抽象类的意义在于它以抽象方法的形式缺少功能。如果一个类没有任何抽象行为(在不同类型之间变化)，那么它可能是一个具体的类。

抽象类是类

下面是类的一些常规特性，这些特性在抽象类中是可用的，但在接口中是不可用的:

实例变量/非最终变量。因此…… 可以访问和修改对象状态的方法 私有/受保护成员(但请参阅Java 9的注释) 扩展抽象或具体类的能力 构造函数

关于抽象类需要注意的几点:

它们不可能是最终的(因为它们的全部目的是扩展) 扩展另一个抽象类的抽象类继承其所有抽象方法作为自己的抽象方法

抽象方法

抽象类和接口都可以有0到多个抽象方法。抽象方法:

是没有主体的方法签名(即没有{}) 在抽象类中必须用abstract关键字标记。在接口中，该关键字是不必要的 不能是私有的(因为它们需要由另一个类实现) 不能最终确定(因为他们还没有身体) 不能是静态的(因为原因)

还要注意:

抽象方法可以由同一类/接口中的非抽象方法调用 扩展抽象类或实现接口的第一个具体类必须为所有抽象方法提供实现

静态方法

抽象类上的静态方法可以直接使用MyAbstractClass.method()调用;(例如，就像一个普通的类，它也可以通过一个扩展抽象类的类来调用)。

接口也可以有静态方法。它们只能通过接口的名称来调用(MyInterface.method();)。这些方法:

不能是抽象的，即必须有一个主体(参见上面的“因为原因”) 不是默认值(见下文)

默认的方法

接口可以有默认方法，该方法必须有default关键字和方法体。这些方法只能引用其他接口方法(不能引用特定实现的状态)。这些方法:

不是静止的 不是抽象的(他们有一个主体) 不能为最终值(名称“default”表示它们可能被覆盖)

如果一个类实现了两个具有相同签名的缺省方法的接口，则会导致编译错误，这可以通过覆盖该方法来解决。

接口可以有静态的final常量

接口只能包含上面描述的方法类型或常量。

常量被假定为静态的和最终的，并且可以在实现接口的类中不加限制地使用。

所有接口成员都是公共的

在Java 8中，接口的所有成员(以及接口本身)都被假定为公共的，不能被保护或私有(但Java 9确实允许接口中的私有方法)。

这意味着实现接口的类必须定义具有公共可见性的方法(与常规规则一致，方法不能被低可见性覆盖)。

我将尝试用实际场景来回答，以说明两者之间的区别。

接口是零负载的，即不需要维护状态，因此将契约(能力)与类关联是更好的选择。

例如，说我有一个执行一些操作的任务类，现在在单独的线程中执行一个任务，我不需要扩展线程类，更好的选择是使任务实现可运行的接口(即实现其run()方法)，然后将此任务类的对象传递给线程实例并调用其start()方法。

现在你可以问，如果Runnable是一个抽象类呢?

从技术上讲，这是可能的，但从设计角度来看，这是一个糟糕的选择原因:

Runnable没有与之相关的状态，也没有“提供”任何状态 run()方法的默认实现 Task必须扩展它，因此它不能扩展任何其他类 Task没有提供任何专门化到Runnable类，它所需要的只是重写run()方法

换句话说，Task类需要在线程中运行的能力，这是通过实现Runnable接口而实现的，而扩展thread类则使其成为线程。

简单地把我们的接口定义为一种能力(契约)，而使用 的抽象类，用于定义的框架(公共/部分)实现 它。

免责声明:下面是愚蠢的例子，尽量不要判断:-P

interface Forgiver {
    void forgive();
}

abstract class GodLike implements Forgiver {
    abstract void forget();
    final void forgive() {
        forget();
    }
}

现在你可以选择成为神一样的人，但你可以选择只成为宽恕者(即不成为神一样的人)，并做:

class HumanLike implements Forgiver {
    void forgive() {
       // forgive but remember    
    }
}

或者你可以选择像上帝一样去做:

class AngelLike extends GodLike {
    void forget() {
       // forget to forgive     
    }
}

P.S.与java 8接口也可以有静态以及默认(可重写实现)方法，因此区别b/w接口和抽象类甚至更窄。

简而言之，我想这样回答:

通过类层次结构进行继承意味着状态继承; 而通过接口继承则代表行为继承;

抽象类可以被视为介于这两种情况之间的东西(它引入了一些状态，但也迫使你定义一个行为)，完全抽象类是一个接口(据我所知，这是c++中仅由虚拟方法组成的类的进一步发展)。

当然，从Java 8开始，事情发生了轻微的变化，但思想仍然是一样的。

我想这对于一个典型的Java面试来说已经足够了，如果你不是被编译器团队面试的话。

Many junior developers make the mistake of thinking of interfaces, abstract and concrete classes as slight variations of the same thing, and choose one of them purely on technical grounds: Do I need multiple inheritance? Do I need some place to put common methods? Do I need to bother with something other than just a concrete class? This is wrong, and hidden in these questions is the main problem: "I". When you write code for yourself, by yourself, you rarely think of other present or future developers working on or with your code.

接口和抽象类，虽然从技术的角度来看很相似，但它们的含义和目的完全不同。

总结

接口定义了一个契约，由某个实现为您实现。 抽象类提供了您的实现可以重用的默认行为。

以上两点正是我在面试时所寻求的，并且是一个足够紧凑的总结。阅读更多细节。

替代的总结

接口用于定义公共api 抽象类用于内部使用和定义spi

通过例子

To put it differently: A concrete class does the actual work, in a very specific way. For example, an ArrayList uses a contiguous area of memory to store a list of objects in a compact manner which offers fast random access, iteration, and in-place changes, but is terrible at insertions, deletions, and occasionally even additions; meanwhile, a LinkedList uses double-linked nodes to store a list of objects, which instead offers fast iteration, in-place changes, and insertion/deletion/addition, but is terrible at random access. These two types of lists are optimized for different use cases, and it matters a lot how you're going to use them. When you're trying to squeeze performance out of a list that you're heavily interacting with, and when picking the type of list is up to you, you should carefully pick which one you're instantiating.

On the other hand, high level users of a list don't really care how it is actually implemented, and they should be insulated from these details. Let's imagine that Java didn't expose the List interface, but only had a concrete List class that's actually what LinkedList is right now. All Java developers would have tailored their code to fit the implementation details: avoid random access, add a cache to speed up access, or just reimplement ArrayList on their own, although it would be incompatible with all the other code that actually works with List only. That would be terrible... But now imagine that the Java masters actually realize that a linked list is terrible for most actual use cases, and decided to switch over to an array list for their only List class available. This would affect the performance of every Java program in the world, and people wouldn't be happy about it. And the main culprit is that implementation details were available, and the developers assumed that those details are a permanent contract that they can rely on. This is why it's important to hide implementation details, and only define an abstract contract. This is the purpose of an interface: define what kind of input a method accepts, and what kind of output is expected, without exposing all the guts that would tempt programmers to tweak their code to fit the internal details that might change with any future update.

抽象类介于接口和具体类之间。它应该帮助实现共享常见或无聊的代码。例如，AbstractCollection提供了基于大小为0的isEmpty的基本实现，contains作为迭代和比较，addAll作为重复添加，等等。这使得实现将重点放在区分它们的关键部分:如何实际存储和检索数据。

另一个角度:api与spi

接口是代码不同部分之间的低内聚网关。它们允许库的存在和发展，而不会在内部发生变化时影响到每个库的用户。它被称为应用程序编程接口，而不是应用程序编程类。在较小的规模上，它们还允许多个开发人员在大型项目上成功协作，通过良好的文档接口分离不同的模块。

抽象类是在实现接口时使用的高内聚帮助器，假设有某种级别的实现细节。或者，抽象类用于定义服务提供者接口(spi)。

API和SPI之间的区别很微妙，但很重要:对于API，重点在于谁使用它，而对于SPI，重点在于谁实现它。

Adding methods to an API is easy, all existing users of the API will still compile. Adding methods to an SPI is hard, since every service provider (concrete implementation) will have to implement the new methods. If interfaces are used to define an SPI, a provider will have to release a new version whenever the SPI contract changes. If abstract classes are used instead, new methods could either be defined in terms of existing abstract methods, or as empty throw not implemented exception stubs, which will at least allow an older version of a service implementation to still compile and run.

关于Java 8和默认方法的说明

尽管Java 8为接口引入了默认方法，这使得接口和抽象类之间的界限更加模糊，但这并不是为了实现可以重用代码，而是为了更容易地更改既作为API又作为SPI(或者被错误地用于定义SPI而不是抽象类)的接口。

“书本知识”

OP回答中提供的技术细节被认为是“书本知识”，因为这通常是在学校和大多数关于语言的技术书籍中使用的方法:一个东西是什么，而不是如何在实践中使用它，特别是在大规模应用中。

打个比方:假设问题是:

舞会之夜租什么更好，一辆车还是一间酒店房间?

技术上的答案是这样的:

嗯，在车里你可以做得更快，但在酒店房间里你可以做得更舒服。另一方面，酒店房间只在一个地方，而在汽车里你可以在更多的地方这样做，比如，你可以去远景点看风景，或者在汽车电影院，或者很多其他地方，甚至不止一个地方。而且，酒店房间里有淋浴。

这都是真的，但完全忽略了一点，那就是它们是两种完全不同的东西，两者都可以同时用于不同的目的，“做”方面并不是这两种选择中最重要的事情。这个答案缺乏视角，它显示了一种不成熟的思维方式，而正确地呈现了真实的“事实”。

接口就像一组公开记录的具有某种影响的基因:DNA测试会告诉我是否有它们——如果我有，我可以公开让人们知道我是“携带者”，我的部分行为或状态将符合它们。(当然，我可能还有很多其他基因，这些基因提供的特征超出了这个范围。)

抽象类就像单性别物种的死去的祖先(*):她不能被复活，但一个活着的(即非抽象的)后代继承了她所有的基因。

为了扩展这个比喻，我们假设这个物种的所有成员都活到相同的年龄。这意味着一个死去的祖先的所有祖先也必须是死的——同样，一个活着的祖先的所有后代也必须是活着的。

接口是一个“契约”，其中实现契约的类承诺实现方法。举个例子，当我将一款游戏从2D升级到3D时，我不得不编写一个界面而不是类。我必须创建一个界面来共享2D和3D版本的游戏类别。

package adventure;
import java.awt.*;
public interface Playable {
    public void playSound(String s);
    public Image loadPicture(String s);    
}

然后我可以实现基于环境的方法，同时仍然能够从一个不知道正在加载的游戏版本的对象调用这些方法。

公共类Adventure扩展了JFrame实现了Playable

公共类Dungeon3D扩展了SimpleApplication实现的Playable

公共类Main扩展了SimpleApplication实现了AnimEventListener ActionListener,播放

通常，在游戏世界中，世界可以是一个抽象类，在游戏中执行方法:

public abstract class World...

    public Playable owner;

    public Playable getOwner() {
        return owner;
    }

    public void setOwner(Playable owner) {
        this.owner = owner;
    }