看看这个例子:

public class Test {

    public static void main(String[] args) {
        int[] x=new int[-5];//compile time no error
        System.out.println(x.length);
    }}

上面的代码编译成功，没有语法错误，完全有效。 但是在运行时，它抛出以下错误。

Exception in thread "main" java.lang.NegativeArraySizeException
    at Test.main(Test.java:5)

比如在编译时检查了某些情况，在运行时检查了某些情况，一旦程序满足所有条件，就会得到输出。 否则，您将得到编译时或运行时错误。

我一直认为它与程序处理开销以及它如何影响性能有关，如前所述。一个简单的例子是，在代码中定义对象所需的绝对内存。

一个定义的布尔值占用x个内存，然后在编译后的程序中，不能更改。当程序运行时，它确切地知道为x分配多少内存。

另一方面，如果我只是定义了一个泛型对象类型(即一种未定义的占位符或可能是一个指向一些巨大blob的指针)，我的对象所需的实际内存是不知道的，直到程序运行，我分配了一些东西给它，因此它必须评估和内存分配等，然后将在运行时动态处理(更多的运行时开销)。

如何动态处理它取决于语言、编译器、操作系统、你的代码等等。

然而，在这一点上，它实际上取决于您使用运行时和编译时的上下文。

例如:在强类型语言中，类型可以在编译时或运行时检查。在编译时，这意味着如果类型不兼容，编译器将报错。在运行时，意味着你可以很好地编译你的程序，但在运行时，它会抛出一个异常。

编制时间:

在编译时执行的操作在最终程序运行时几乎不会产生任何开销，但在构建程序时可能会产生很大开销。

运行时:

或多或少完全相反。构建时成本小，运行程序时成本大。

从另一边;如果在编译时执行了某些操作，那么它只在您的机器上运行;如果在运行时执行了某些操作，那么它将在用户的机器上运行。

相关性

An example of where this is important would be a unit carrying type. A compile time version (like Boost.Units or my version in D) ends up being just as fast as solving the problem with native floating point code while a run-time version ends up having to pack around information about the units that a value are in and perform checks in them along side every operation. On the other hand, the compile time versions requiter that the units of the values be known at compile time and can't deal with the case where they come from run-time input.

编制时间:

在编译时执行的操作在最终程序运行时几乎不会产生任何开销，但在构建程序时可能会产生很大开销。 运行时:

或多或少完全相反。构建时成本小，运行程序时成本大。

从另一边;如果在编译时执行了某些操作，那么它只在您的机器上运行;如果在运行时执行了某些操作，那么它将在用户的机器上运行。

运行时和编译时的主要区别是:

如果代码中存在语法错误和类型检查，则抛出编译时错误，而-as运行时:它在执行代码后进行检查。 例如:

Int a = 1 Int b = a/0;

这里的第一行末尾没有分号——在执行操作b时执行程序后，>编译时错误，结果是无限的——>运行时错误。

编译时不会查找代码提供的功能的输出，而运行时则会。