java performance 中文_Java Performance Tuning

Does using * in an import statement affect performance?

This question has come up a surprising number of times in various forums. The question relates to the import directive, as in

import java.util.*;

The short answer is: no, there is no affect on runtime performance.

The import directive is a compiler directive. The Java source to bytecode compiler reads the Java source file (i.e. a something.java file) and converts that source to one or more bytecode files (.class files).

Most Java source code in the Java source file is converted into Java bytecodes of one sort or another. But the import directive is not. The import directive specifically tells the compiler to do something. The import directive tells the compiler that when it comes across a class or interface name in the source file, e.g. HashMap, then if it cannot find the class file for that name, it should use the import statement to help it look it up. This way, you don't have to always use fully qualified class names, e.g. java.util.HashMap.

The import directives themselves do not get put into the compiled bytecode files. They are no longer of any use, as the compiler compiles the fully qualified name into the .class file.

For example, suppose the source file contains

import java.util.*;

//

...

HashMap map;

...

Then the compiler gets to the HashMap map variable declaration, tries to find a class called HashMap in the default package (i.e. no package name), fails, and uses the import statement to see if there is a java.util.HashMap class. This is found, and a reference tojava.util.HashMap is inserted into the .class file. After compilation is completed, there is no use for the import directive, so it is not present at all in the compiled bytecode. Consequently, the import directive cannot affect runtime code execution in any way.

However, it is worth noting that the directive does affect compilation time. Since the directive tells the compiler how to do a second lookup to find classes, obviously this means that more time is spent looking up class and interface names compared to if one lookup sufficed.

In fact, there are two forms of the import directive: with and without the wildcard '*', e.g.

import java.util.*;

import java.util.HashMap;

Without the wildcard, the directive tells the compiler to look for one specific file in the classpath. With the wildcard, the directive is telling the compiler to look for the named package, and to search in that package for possible matches everytime any name needs to be matched. This latter version is probably going to be more costly (i.e. take longer) for the compiler than the former.

Also, depending on which compiler you use, and which settings, the compiler may re-compile all of the classes in the wildcard package, which could really make things take longer.

Finally, many people find that using imports with wildcards makes the source much less readable, since the reader also needs to figure out which package a particular class comes from, rather than just looking it up in the import statement.

So the full answer is

There is no runtime cost from using an import statement

The compilation process can take a little more time with an import statement

The compilation process can take even more time with a wildcard import statement

For improved readability, wildcard import statements are bad practice for anything but throwaway classes

The compilation overhead of non-wildcard import statements are minor, but they give readability benefits so best practice is to use them

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
“The definitive master class in performance tuning Java applications…if you love all the gory details, this is the book for you.” –James Gosling, creator of the Java Programming Language Improvements in the Java platform and new multicore/multiprocessor hardware have made it possible to dramatically improve the performance and scalability of Java software. JavaPerformance covers the latest Oracle and third-party tools for monitoring and measuring performance on a wide variety of hardware architectures and operating systems. The authors present dozens of tips and tricks you’ll find nowhere else. You’ll learn how to construct experiments that identify opportunities for optimization, interpret the results, and take effective action. You’ll also find powerful insights into microbenchmarking–including how to avoid common mistakes that can mislead you into writing poorly performing software. Then, building on this foundation, you’ll walk through optimizing the Java HotSpot VM, standard and multitiered applications; Web applications, and more. Coverage includes Taking a proactive approach to meeting application performance and scalability goals Monitoring Java performance at the OS level in Windows, Linux, and Oracle Solaris environments Using modern Java Virtual Machine (JVM) and OS observability tools to profile running systems, with almost no performance penalty Gaining “under the hood” knowledge of the Java HotSpot VM that can help you address most Java performance issues Integrating JVM-level and application monitoring Mastering Java method and heap (memory) profiling Tuning the Java HotSpot VM for startup, memory footprint, response time, and latency Determining when Java applications require rework to meet performance goals Systematically profiling and tuning performance in both Java SE and Java EE applications Optimizing the performance of the Java HotSpot VM Using this book, you can squeeze maximum performance and value from all your Java applications–no matter how complex they are, what platforms they’re running on, or how long you’ve been running them.

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值