Java能不能像C语言不通过JVM虚拟机直接编译成二进制机器码，让计算机直接运行？

新司机上路，思考一个问题。如果Java直接编译成机器码，这样岂不解决了Java运行缓慢的问题，进而淘汰或者取代C语言。（这里，不是说就此取消Java的JVM解释型运行的机制，我的意思这两种方式并存。）衍生问题：C语言为什么不设计一个C语言虚拟机，这样扩展C语言的跨平台性。

自己思考的角度回答自己的问题，不够全面，希望大家补充，感谢各位大佬！
看到很多别人的回答，有一句话非常惊艳。

通常，没有“必须这么设计”的绝对理由，之所以会是这样，只是因为被设计成这样。

还有一句话，也讲的非常好。

语言本身与是否是解释型或者编译型无关。

从这两个观点，我自己获得了一些看法。理论上，不管是Java还是C，应该都存在解释型以及编译型，肯定会有人这么尝试过，但是因为最终Java与C的不同定位，导致最终这种形态并非主流，随之被淘汰。

好比，你告诉自行车，摩托车能开这么快，你为什么设计成摩托车。自行车拥有轻便的特性，摩托车拥有快速的特性，两者不可兼得。但是，有人为了得到两者的优点，出现了电动自行车，但是于此同时它拥有的两个特性又逊色于前两者。

衍生的思考，之所以Java不设计成直接编译成二进制机器码给发给主机，是因为保持Java的编译二进制字节码再边编译边执行拥有前者不具备的优势，例如，具备一码（字节码）通天下的跨平台性。还有一种提问，为什么一定要边编译边执行，不一次性全编译然后再执行。的确，有人这么做过，但是最终发现这样并非最优解。例如，等待JVM全编译后执行，会影响启动展示的速度，其次边编译边执行，当JVM发现不停调用同一个接口，会动态虚拟调用，节约资源，进一步优化。

总结，事出反常必有妖，存在即合理。而求问的目的就是，得到这个合理的解释究竟是什么。基于不断追求最优解的前提底下，不存在绝对最优解，只存在相对最优解，因为不同的应用场景有不同的针对性，导致不同的解决方案，也就形成了不同的语言体系。

Java面向对象，更简单易懂。C面向过程，直接操作内存，可以写出更加节省资源的代码。把简单易懂与节省资源分成两极，Java能够静态编译后再执行，既保持简单易懂兼并节省资源。
除非，节约这点资源显得没意义，不如走两个极端。随后有更加极端简易的Python，Java就变成了中间选择。

猜想：就BS结构而言，如果在服务器端静态编译好各个平台所需的机器码（C语言静态编译），然后客户端访问服务器提交客户端平台识别信息，由此获取所对应的机器码，返回执行，这样是否更加的提高运行速度？理论上是，但是遇到几个问题。这些问题顺便解释了为什么这种方式不适合做BS，以及什么叫做跨平台性差。基于我们理解的平台可能有安卓，windows，Linux等，我们下意识认为平台数量是有限的，只要准备好这些主流平台即可，实际上，平台是无限的，大到宇宙飞船，小到摄像头，各种不同物件，也可能在未来不断产生不同的平台，开发者无法针对不同平台进行提前准备机器码。但是，可以针对不同平台开发不同的虚拟机，这样就形成了可扩展性，而不用去动服务器上面的代码。

故而C语言更多应用于安装本地的应用软件，因为它不会产生不同平台的访问。

换言之，Java是被动让不同的设备兼容它，而C则是主动去兼容不同设备。

最后

以上就是直率小松鼠为你收集整理的Java能不能像C语言不通过JVM虚拟机直接编译成二进制机器码，让计算机直接运行？的全部内容，希望文章能够帮你解决Java能不能像C语言不通过JVM虚拟机直接编译成二进制机器码，让计算机直接运行？所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。