为什么编译的Java类文件小于C编译文件？
我想知道为什么我们通过编译打印“Hello，World！”的.c文件获得的.o文件。 大于Java .class文件，也打印“Hello，World！”？
Java使用Bytecode是独立于平台并且“预编译”的，但字节码由解释器使用并且足够紧凑，因此它与您在编译的C程序中可以看到的机器代码不同。 只需看看Java编译的完整过程：
Java program -> Bytecode -> High-level Intermediate Representation (HIR) -> Middle-level Intermediate Representation (MIR) -> Low-level Intermediate Representation (LIR) -> Register allocation -> EMIT (Machine Code) 这是Java程序到机器代码转换的链。 如您所见，字节码远离机器代码。 我在互联网上找不到好东西向你展示真实程序的这条路（一个例子），我发现的一切都是这个演示文稿 ，在这里你可以看到每个步骤如何改变代码的呈现方式。 我希望它能回答你如何以及为什么编译的c程序和Java字节码是不同的。
更新： “字节码”之后的所有步骤都是由JVM在运行时完成的，这取决于它编译该代码的决定（这是另一个故事…… JVM在字节码解释和编译到本机平台相关代码之间取得平衡）
最后找到了一个很好的例子，取自Java HotSpot™客户端编译器的线性扫描寄存器分配 （顺便说一下，了解JVM内部的情况）。 想象一下，我们有java程序：
public static void fibonacci() { int lo = 0; int hi = 1; while (hi < 10000) { hi = hi + lo; lo = hi - lo; print(lo); } }
然后它的字节码是：
0: iconst_0 1: istore_0 // lo = 0 2: iconst_1 3: istore_1 // hi = 1 4: iload_1 5: sipush 10000 8: if_icmpge 26 // while (hi < 10000) 11: iload_1 12: iload_0 13: iadd 14: istore_1 // hi = hi + lo 15: iload_1 16: iload_0 17: isub 18: istore_0 // lo = hi - lo 19: iload_0 20: invokestatic #12 // print(lo) 23: goto 4 // end of while-loop 26: return
每个命令占用1个字节（JVM支持256个命令，但实际上少于该数量）+参数。 它需要27个字节。 我省略了所有阶段，现在可以执行机器代码：
00000000: mov dword ptr [esp-3000h], eax 00000007: push ebp 00000008: mov ebp, esp 0000000a: sub esp, 18h 0000000d: mov esi, 1h 00000012: mov edi, 0h 00000017: nop 00000018: cmp esi, 2710h 0000001e: jge 00000049 00000024: add esi, edi 00000026: mov ebx, esi 00000028: sub ebx, edi 0000002a: mov dword ptr [esp], ebx 0000002d: mov dword ptr [ebp-8h], ebx 00000030: mov dword ptr [ebp-4h], esi 00000033: call 00a50d40 00000038: mov esi, dword ptr [ebp-4h] 0000003b: mov edi, dword ptr [ebp-8h] 0000003e: test dword ptr [370000h], eax 00000044: jmp 00000018 00000049: mov esp, ebp 0000004b: pop ebp 0000004c: test dword ptr [370000h], eax 00000052: ret
结果需要83（hex为52 + 1字节）字节。
PS。 我没有考虑链接（被别人提到），以及compilec和字节码文件头（可能它们也不同;我不知道它是如何与c，但在字节码文件中所有字符串都移动到特殊的标题池，并在程序中使用其标题中的“位置”等）
UPDATE2：可能值得一提的是，java使用stack（istore / iload命令），虽然基于x86和大多数其他平台的机器代码与寄存器一起工作。 正如您所看到的，机器代码是“完整”的寄存器，与更简单的基于堆栈的字节码相比，它为编译的程序提供了额外的大小。
在这种情况下，尺寸差异的主要原因是文件格式的差异。 对于ELF（ .o ）文件的这种小程序格式，在空间方面引入了严重的开销。
例如，我的“Hello，world”程序的示例.o文件占用864个字节 。 它由（使用readelf命令探索）组成：
- 52个字节的文件头
- 440字节的节头（40字节x 11节）
- 81个字节的节名
- 160字节的符号表
- 43个字节的代码
- 14个字节的数据 （
Hello, world\n\0） - 等等
类似程序的.class文件只占用415个字节 ，尽管它包含更多符号名称并且这些名称很长。 它由（使用Java Class Viewer进行探索）组成：
- 289个字节的常量池（包括常量，符号名称等）
- 94字节的方法表（代码）
- 8个字节的属性表（源文件名参考）
- 24字节的固定大小的标头
也可以看看：
- 可执行和可链接的格式
- Java类文件
- Java类查看器
C程序，即使它们被编译为在您的处理器上运行的本机机器代码（当然也是通过操作系统发送），往往需要为操作系统进行大量设置和拆卸，加载动态链接像C库等库。
另一方面，Java编译为虚拟平台的字节码（基本上是计算机内的模拟计算机），它是专门与Java本身一起设计的，因此需要大量的开销（如果这两者都是必要的话）代码和VM接口定义明确）可以移动到VM本身，使程序代码保持精简。
然而，它在编译器到编译器之间有所不同，并且有几种选择可以减少它或以不同方式构建代码，这将产生不同的效果。
所有这些说，它并不是那么重要。
简而言之：Java程序被编译为Java字节代码，这需要执行单独的解释器（Java虚拟机）。
c编译器生成的.o文件比Java编译器生成的.class文件小，并非100％保证。 这一切都取决于编译器的实现。
.o和.class文件大小不同的一个主要原因是Java字节码比机器指令高一点。 当然不是更高级别 – 它仍然是相当低级的东西 – 但这会产生影响，因为它有效地压缩整个程序。 （C和Java代码都可以有启动代码。）
另一个区别是Java类文件通常代表相对较小的function。 虽然可以将C对象文件映射到更小的片段，但在单个文件中放置更多（相关）function通常更为常见。 范围规则的差异也可以强调这一点（C实际上没有任何与模块级范围相对应的内容，但它确实具有文件级范围; Java的包范围适用于多个类文件）。 如果比较整个程序的大小，您会得到更好的指标。
就“链接”大小而言，Java可执行JAR文件往往更小（对于给定的function级别），因为它们是经过压缩的。 以压缩forms提供C程序相对较少。 （标准库的大小也存在差异，但它们也可能是一种清洗，因为C程序可以依赖libc以外的库，而Java程序可以访问一个巨大的标准库。挑选具有优势的人很尴尬。）
然后，还有调试信息的问题。 特别是，如果您编译一个带有调试function的C程序，那么您将获得有关标准库中包含类型的大量信息，只是因为过滤它有点太尴尬了。 Java代码只有关于实际编译代码的调试信息，因为它可以依赖目标文件中可用的相关信息。 这会改变代码的实际大小吗？ 不，但它会对文件大小产生很大影响。
总的来说，我猜想很难比较C和Java程序的大小。 或者更确切地说，您可以比较它们并轻松学习没什么用处。
ELF格式.o文件的大多数（简单函数多达90％）是垃圾。 对于包含单个空函数体的.o文件，您可以预期大小细分如下：
- 1％的代码
- 9％符号和重定位表（对于链接至关重要）
- 90％的头文件开销，编译器和/或汇编器存储的无用版本/供应商注释等。
如果要查看已编译C代码的实际大小，请使用size命令。
类文件是Java字节代码。
它很可能更小，因为C / C ++库和操作系统库链接到C ++编译器生成的目标代码，最终生成可执行二进制文件。
简单地说，就像将Java字节代码与C编译器生成的目标代码进行比较，然后将其链接到创建二进制文件。 不同之处在于JVM解释Java字节代码以正确执行程序要执行的操作，而C需要来自操作系统的信息，因为操作系统充当解释器。
同样在C中，每个符号（函数等）都会导入一个外部库，至少在一个目标文件中引用一次。 如果您在多个目标文件中使用它，它仍然只导入一次。 这种“导入”有两种方式可以实现。 使用静态链接，函数的实际代码将复制到可执行文件中。 这会增加文件大小，但其优点是不需要外部库（.dll / .so文件）。 使用动态链接时，这不会发生，但结果是您的程序需要运行其他库。
在Java中，一切都是动态地“链接”，可以这么说。
Java被编译成与机器无关的语言。 这意味着在编译之后，它将由Java虚拟机（JVM）在运行时进行转换。 C被编译为机器指令，因此是程序在目标机器上运行的所有二进制文件。
由于Java编译为与机器无关的语言，因此特定计算机的特定详细信息由JVM处理。 （即C具有机器特定的开销）
无论如何，这就是我的想法:-)
一些潜在的原因：
- Java类文件根本不包含初始化代码。 它只有你的一个类和一个函数 – 确实非常小。 相比之下，C程序有一定程度的静态链接初始化代码，可能还有DLL thunk。
- C程序也可能具有与页面边界对齐的部分 – 这将为程序大小添加至少4kb，以确保代码段在页面边界上开始。