我主要学的编程语言是JAVA,我想了解一下JAVA的性能。由于我没做过大型项目,不知道项目做大以后的性能到底如何,所以我想请教一下,尤其是知道JAVA、jvm底层原理和做过大规模项目的人来说一下。
对于各类应用程序和系统组件的开发,JAVA速度慢于C/C++是质上的问题还是量上的问题?所谓质上的问题,就是说能力上缺少了很多的东西,比如mysql和oracle相比,运行速度快而简单,但是缺少某些功能特性,那些功能特性在小型数据库上根本用不上,但是当数据库和程序规模无限扩大的时候,没这些功能和特性的缺少导致其性能和稳定性下降,甚至导致有些任务在大规模项目中mysql做不了,或者代价无法承受。所谓量上的问题,就是说速度慢、耗资源可以控制在一定范围以内,比如小型项目,会多耗80%的CPU和内存,而大型项目,功能和性能特性其实也不会有改变,只要程序设计的好,理论上仍然是多耗80%的CPU和内存,不会因为规模的扩大而导致缺少某些必要的性能,或者是消耗的资源成倍增长,甚至完全无法完成任务。另外我还想请教一下,具体是哪些类型的操作会导致JAVA性能差,如何避免这些缺陷,或者说哪些情况下可以避免或者较少导致这些缺陷?
很多人都说JAVA开发WEB好,其实我觉得WEB程序模式比较单调,而且我觉得JAVA这方面的优势其实只是因为SUN较早的投入在了WEB领域,导致JAVA开发环境很早就拥有了成熟的库支持以及使用环境,其他WEB发展晚的语言追赶这种环境代价太大,而且JAVA在WEB开发中已经是一种标准,但是从原理的角度,如果C++较早的投入到WEB开发,设计出类型JSP和配套的框架,其实也不会有什么劣势。JAVA最大的优势有2个:我觉得一个是在J2EE上有很多类库和配套功能,但是这个还是可以被其他语言赶超的,只是赶超起来比较困难而已,二是JVM,这是JAVA最核心部分,使得程序员不必关心硬件环境,简化了很多操作,提高了开发效率,其实也是劣势,因为不能操作硬件。大家最常说的可移植性其实算不上什么巨大优势,因为用统一标准写的C++也是几乎可以在任何平台编译,至于说少数另类CPU,我觉得始终是要被INTER和AMD的指令集所同化的。
对于各类应用程序和系统组件的开发,JAVA速度慢于C/C++是质上的问题还是量上的问题?所谓质上的问题,就是说能力上缺少了很多的东西,比如mysql和oracle相比,运行速度快而简单,但是缺少某些功能特性,那些功能特性在小型数据库上根本用不上,但是当数据库和程序规模无限扩大的时候,没这些功能和特性的缺少导致其性能和稳定性下降,甚至导致有些任务在大规模项目中mysql做不了,或者代价无法承受。所谓量上的问题,就是说速度慢、耗资源可以控制在一定范围以内,比如小型项目,会多耗80%的CPU和内存,而大型项目,功能和性能特性其实也不会有改变,只要程序设计的好,理论上仍然是多耗80%的CPU和内存,不会因为规模的扩大而导致缺少某些必要的性能,或者是消耗的资源成倍增长,甚至完全无法完成任务。另外我还想请教一下,具体是哪些类型的操作会导致JAVA性能差,如何避免这些缺陷,或者说哪些情况下可以避免或者较少导致这些缺陷?
很多人都说JAVA开发WEB好,其实我觉得WEB程序模式比较单调,而且我觉得JAVA这方面的优势其实只是因为SUN较早的投入在了WEB领域,导致JAVA开发环境很早就拥有了成熟的库支持以及使用环境,其他WEB发展晚的语言追赶这种环境代价太大,而且JAVA在WEB开发中已经是一种标准,但是从原理的角度,如果C++较早的投入到WEB开发,设计出类型JSP和配套的框架,其实也不会有什么劣势。JAVA最大的优势有2个:我觉得一个是在J2EE上有很多类库和配套功能,但是这个还是可以被其他语言赶超的,只是赶超起来比较困难而已,二是JVM,这是JAVA最核心部分,使得程序员不必关心硬件环境,简化了很多操作,提高了开发效率,其实也是劣势,因为不能操作硬件。大家最常说的可移植性其实算不上什么巨大优势,因为用统一标准写的C++也是几乎可以在任何平台编译,至于说少数另类CPU,我觉得始终是要被INTER和AMD的指令集所同化的。
解决方案 »
- JTextField setText 问题
- 一道关于Servlet的面试题
- 关于加 wav声音的个小问题哦(在线急求 )
- 关于Inner classes 和 abstract class 的问题:
- java怎么向命令行程序传递参数啊?(100求助)
- 我在tomcat4。1。24上配连接池连接oracle数据库,不成功,出现Cannot load JDBC driver class 'null'异常,各位知道是什么原因吗?我是照
- 七星彩问题-谁给我说一下思路
- 字符串重组问题
- 我女朋友老师布置的一道简单的作业!要求用java实现。
- 怎么interrupt线程
- 关于java设计结构
- eclipse下 windowbuilder如何切换到控件界面
所谓量上的问题,就是说速度慢、耗资源可以控制在一定范围以内,比如小型项目,会多耗80%的CPU和内存,而大型项目,功能和性能特性其实也不会有改变,只要程序设计的好,理论上仍然是多耗80%的CPU和内存,不会因为规模的扩大而导致缺少某些必要的性能,或者是消耗的资源成倍增长,甚至完全无法完成任务。主要是这两句,其他的只是个人一些感觉,可能是错误的,嫌麻烦就看这两句就可以了。
1.对象分配于堆,现在已经被新的JVM(其中的JIT编译器)解决了,所以老的JIT才会有这种情况。
2.某些原因有少量的额外内存开销。
3.使用容器导致额外CPU开销。现在被JIT优化了很多,几乎不会出现这种情况。
4.JVM的工作原理会导致额外内存开销(JVM会导致cache命中降低,尤其是在小程序刚刚启动时)。
5.缺乏低级功能,JVM操作不了的,开发者也操作不了(我想这里主要是指硬件层面的)。影响速度的主要是前4条,1、3几乎已经都被JIT层面解决了,不需要程序员考虑,2影响不大。主要是第4条,高速缓存命中率低,没命中就需要访问内存,而访问内存的速度肯定比访问缓存慢,另外还有额外的内存开销。不过内存和缓存的访问速度基本是成比例的,所以不会因为项目规模变大而导致JAVA的速度和C++的差距更大,JVM额外开销一定的内存我觉得也是允许的(也是无法避免的),现在硬件的瓶颈也并不是在内存。维基百科的这段文字:
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B
While C++ is faster than Java in most cases,[10] there are several studies of mostly numerical benchs, which argue that Java could potentially outperform C++ in some circumstances,.[11][12][13][14] However, it is widely recognized[by whom?] that numerical (micro-)benchs are not appropriate for evaluation of languages; two compilers with different performance on non-numerical sections of code may still be able to optimize numerical sections equally.[15][16][17] If referring to a real world program, Java would suffer for a number of reasons:[18][19][20]All objects are allocated on the heap. For functions using small objects this can result in huge performance degradation as stack allocation, in contrast, costs essentially zero. However, this advantage is obsoleted by modern JIT compilers utilising escape analysis or escape detection to allocate objects on the stack.
Methods are by-default virtual. This slightly increases memory usage by adding a single pointer to a virtual table per each object. Also, it induces a startup performance penalty, because a JIT compiler has to do additional optimization passes even for de-virtualization of small functions.
A lot of casting required even using standard containers induces a performance penalty. However, most of these casts are statically eliminated by the JIT compiler, and the casts that remain in the code usually do not cost more than a single CPU cycle on modern processors, thanks to branch prediction.
It is argued[by whom?] that a Virtual Java Machine increases memory usage even further, potentially reducing memory locality and increasing chances of cache misses. This impacts especially startup times of small programs.
Lack of access to low level details does not allow the developer to better optimize the program where the compiler is unable to do so.[21].
It is argued[by whom?], however, that compared to Java, C++ also has a number of downsides:Pointers make optimization difficult since they may point to arbitrary data. However this is obsoleted as new compilers introduced strict-aliasing rule[22] and because of support of the C99 keyword restrict.[23]
Java garbage collection may have better cache coherence than the usual usage of malloc/new for memory allocation, as its allocations are generally made sequentially. Nevertheless, arguments exist that both allocators equally fragment the heap and neither exhibits better cache locality.
Run-time compilation can potentially use additional information available at run-time to optimise code more effectively, such as knowing what processor the code will be executed on. However this claim is effectively made obsolete as most state-of-the-art C++ compilers generate multiple code paths to employ the full computational abilities of the given system [24]
Run-time compilation allows for more aggressive virtual function inlining than it is possible for a static compiler, due to the fact that the JIT compiler has complete information about all possible targets of the virtual call, even if they are in different dynamically loaded modules. Currently available JVM implementations have no problem in inlining most of the monomorphic, mostly monomorphic and bimorphic calls, and a research is in progress to inline also megamorphic calls, thanks to the recent invokedynamic enhancements added in Java 7. [25]
Because in C++ thread support is provided by libraries, C++ compilers have no chance to perform thread-related optimisations. In Java, thread synchronisation is built into the language, so the JIT compiler can, with a help of escape analysis, easily elide or coarse locks, significantly improving performance of multithreaded code. This technique was introduced in Sun JDK 6 update 10 and is named biased locking [26]
In C++, heap allocation and deallocation using new/delete is slower than heap allocation in Java, because in C++ the allocator has to find a block of free memory of appropriate size in such a way that the heap fragmentation is kept reasonably low. On the contrary, Java allocates always from the contiguous block of memory, so the allocation is not more difficult than increasing a single pointer. Additionally, deallocating short-lived objects that do not survive garbage collection costs essentially zero. It has been empirically found that most objects in object-oriented languages die young.
现在是硬件发展快于软件发展,所以java成为了主流。
我觉得C语言干的事情无非就是在改变数据的大小和存放地址...
java就像赋予了界面的游戏... 操作方式也跟C完全不一样了
但是没成气候