我主要学的编程语言是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的指令集所同化的。

解决方案 »

  1.   

    对于各类应用程序和系统组件的开发,JAVA速度慢于C/C++是质上的问题还是量上的问题?
    所谓量上的问题,就是说速度慢、耗资源可以控制在一定范围以内,比如小型项目,会多耗80%的CPU和内存,而大型项目,功能和性能特性其实也不会有改变,只要程序设计的好,理论上仍然是多耗80%的CPU和内存,不会因为规模的扩大而导致缺少某些必要的性能,或者是消耗的资源成倍增长,甚至完全无法完成任务。主要是这两句,其他的只是个人一些感觉,可能是错误的,嫌麻烦就看这两句就可以了。
      

  2.   

    java 的运行速度 要比 c++ c 慢些
      

  3.   

    找到比较权威的答案了,自己谷歌搜索到的根据搜索到的结果,总结一下:JAVA对比C++的劣势有一下几项:
    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.
      

  4.   

    至少之前测试tomcat的时候,每秒几千条数据还是可以的。
      

  5.   

    内存方面,自己写程序多注意就行了,java有垃圾回收机制。速度方面,慢一点但是也很快。
    现在是硬件发展快于软件发展,所以java成为了主流。
    我觉得C语言干的事情无非就是在改变数据的大小和存放地址...
    java就像赋予了界面的游戏... 操作方式也跟C完全不一样了
      

  6.   

    好像有直接运行java字节码的CPU,
    但是没成气候
      

  7.   

    csdn上曾经有篇文章 说  如果你只站在语言的层面 你永远都是个程序员! 语言存在既有他的价值 不要比来比去,深入了 自然就会自己感觉到他的优缺点
      

  8.   

    java数据安全性比较高,另外还有垃圾回收机制,可以很好的解决程序员很发愁的内存泄漏问题,java优势在多线程方面比较容易编写,多线程将来是一种趋势,所以说将来java的优势会更加明显 
      

  9.   

    程序是优化出来的,java 不见得就慢,java也在不断地的进步中