Go homepage(回首页)
Upload pictures (上传图片)
Write articles (发文字帖)

The author:(作者)左
published in(发表于) 2013/11/13 7:33:38
Characteristics of 6 Java developers should stay away from

The 6 Java developers should stay away from-Java-IT information Characteristics of 6 Java developers should stay away from

Nikita Salnikov Tarnovski plumbr senior developer, is also an expert on application performance tuning, he has many years of experience in performance tuning. Recently, Tarnovski wrote an article referring to ordinary developers should try to avoid using a Java 6 features, these features commonly found in various frameworks or libraries, but for regular application developers, the use of these characteristics might be a disaster for the application that you have developed.

I have spent countless hours troubleshooting for various different applications. Based on past experience, I can draw a conclusion, that is, for most developers, you should stay away from Java SE features or APIs. That most developers here refers to General Java EE developers, not designers or developers of infrastructure.

Frankly, in the long run, most teams should stay away from the lines of Java features. However there are always exceptions to everything happening. If you have a strong team, always aware of what they are doing, then do it in accordance with your ideas. But for the most part, if you used in the development of the project following the Java features, you'll regret it in the long term.

These should stay away from Java features are:

· The reflection

· The bytecode manipulation

? ThreadLocal

· The class loader

· Weak and soft references

? Sockets

Case-by-case analysis of the characteristics below and see why ordinary Java developers should stay away from them:

Reflection: in the popular libraries such as Spring and Hibernate in reflection, certainly has a place. Business code in many cases but introspection is not a good thing, there are many reasons, under normal circumstances, I always advise people to not use reflection.

First is the code for readability and tool support. Opens the familiar IDE, looking for inside your Java code-dependent, it is hard to come by. Now, replace your code and then use reflection to give it a try, what is the result? If you modify the object that has been packaged by reflection, then the result would become more uncontrollable. Please take a look at the following sample code:

If you do not compile-time security. Just like the example above, you will find that if getDeclaredField () method call parameter is bad, then found only in runtime. Want to know is, look for runtime compile Bug Bug harder than they should be.

Finally, to talk about costs. JIT optimization are different for reflection, some tuning time will take longer, and some of which are unable to apply optimizations. Therefore, sometimes reflective performance penalty can be up to several orders of magnitude difference. But in a typical business application, you might not notice this cost.

To sum up, I think the only reasonable in the business code (direct) using reflection scene is done by AOP. In addition to this, you'd better stay away from reflecting this feature.

Bytecode manipulation: if in Java EE applications using CGLIB ASM or library directly from your code, then I suggest you take a look. Just like before, I referred to the negative impact of reflection, of using bytecode manipulation is reflected several times much pain can.

Worse at compile-time, you will not see the executable code. In essence, you don't know what the product is actually running in the code. Therefore faced with problems during operation, as well as when you are debugging, you should spend a lot more time.

ThreadLocal: see business ThreadLocal if your code makes me tremble, for two reasons. First of all, with the help of ThreadLocal, you can pass a variable without having to explicitly via a method call, and addicted to the practice. In some circumstances it could be reasonable, but if you're not careful, I can guarantee you'll have a huge surprise in the final code dependencies.

Second reason my daily work-related. Data stored in a ThreadLocal is easy to cause memory leaks, at least I can see one in ten permanent leakage is caused by overuse of ThreadLocal. Even similar loader and use of the thread pool, "java.lang.OutOfMemoryError:Permgen space", not far away, waiting for you.

The class loader: the first class loader is a very complex thing. You must first understand them, including hierarchical relations, Commission mechanisms and types of caching, and so on. If you think you are already well versed in the class loader, when at the beginning is that there will be a variety of problems, is likely to lead to a class loader leaks. Therefore, I suggest that you should leave class loader application server use.

Weak references and soft references: about weak references and soft references, do you know what they are and the use of simple way? Now you better understanding about Java kernel, what about the cache will use soft references to override all? Do not too good, so you don't have a hammer in his hand drum.

You may be wondering why I said cache more or less inapplicable uses soft references. After all, the build cache using the soft reference can be a good illustration to entrust certain complexities GC to complete rather than to achieve this norm.

Here is one example. You use soft references to build a cache, so that when memory is exhausted, GC can step in and start cleaning. But now you are simply unable to control which objects are removed from the cache, quite possibly the next cache when this object is no longer recreated again. If the memory is still very tense, and have performed a cleanup and GC is triggered, then chances are, an infinite loop occurs, the app will consume large amounts of CPU time, Full GC will also perform.

Sockets:java.net.Socket is simply too hard to use. Flaw I think it ultimately comes from its obstructive nature. In preparing the typical Java EE applications with a Web front end, you need a high degree of concurrency to support large numbers of users. When all you want to do something that scalability is not so good thread pool to stay there, waiting for blocking Sockets.

There are already a great third-party libraries to solve these problems, don't write your own, try the Netty.

Readers, Java version has experienced a number of changes occurred, each also has many new features added. Daily Java development, do you think what are the Java feature is very easy to cause a problem? Author is not recommended for general application development using reflection, but for the framework or library development, leaving the reflection is actually not possible, such as Spring, Struts2 framework, Java development in General, using reflection you think where necessary? In other words, you can not be fulfilled or if you do not use reflection needs. Article author does not recommend using bytecode manipulation framework actually achieved when certain functions are used to, for example in achieving AOP, Spring using Java dynamic proxies and two ways to reach the CGLib library. For General Java projects, which need about bytecode manipulation? Readers are welcome to speak their minds, to discuss some of the interesting topics.

开发者应该远离的6个Java特性 - Java - IT资讯
开发者应该远离的6个Java特性

Nikita Salnikov Tarnovski是plumbr的高级开发者，也是一位应用性能调优的专家，他拥有多年的性能调优经验。近日，Tarnovski撰文谈到了普通开发者应该尽量避免使用的6个Java特性，这些特性常见于各种框架或库当中，但对于普通的应用开发者来说，使用这些特性也许会给你所开发的应用带来灾难。

我曾花费了无数个小时为各种不同的应用排错。根据过往的经验我可以得出这样一个结论，那就是对于大多数开发者来说，你应该远离几个Java SE特性或是APIs。这里所说的大多数开发者指的是一般的Java EE开发者而不是库设计者或是基础设施开发者。

坦白地说，从长远来看，大多数团队都应该远离如下的Java特性。不过凡事总有例外的情况。如果你有一个强大的团队，总是能够清楚地意识到自己在做什么，那就按照你的想法去做就行。但对于大多数情况来说，如果你在项目的开发中使用了下面这几个Java特性，那么从长远来看你是会后悔的。

这些应该远离的Java特性有：

• 反射

• 字节码操纵

• ThreadLocal

• 类加载器

• 弱引用与软引用

• Sockets

下面对这些特性进行逐个分析，看看为什么普通的Java开发者应该远离他们：

反射：在流行的库如Spring和Hibernate中，反射自然有其用武之地。不过内省业务代码在很多时候都不是一件好事，原因有很多，一般情况下我总是建议大家不要使用反射。

首先是代码可读性与工具支持。打开熟悉的IDE，寻找你的Java代码的内部依赖，很容易吧。现在，使用反射来替换掉你的代码然后再试一下，结果如何呢？如果通过反射来修改已经封装好的对象状态，那么结果将会变得更加不可控。请看看如下示例代码：

如果这样做就无法得到编译期的安全保证。就像上面这个示例一样，你会发现如果getDeclaredField()方法调用的参数输错了，那么只有在运行期才能发现。要知道的是，寻找运行期Bug的难度要远远超过编译期的Bug。

最后还要谈谈代价问题。JIT对反射的优化程度是不同的，有些优化时间会更长一些，而有些甚至是无法应用优化。因此，有时反射的性能损失可以达到几个数量级的差别。不过在典型的业务应用中，你可能不会注意到这个代价。

总结一下，我觉得在业务代码中唯一合理（直接）使用反射的场景是通过AOP。除此之外，你最好远离反射这一特性。

字节码操纵：如果在Java EE应用代码中直接使用了CGLIB或是ASM库，那么我建议你好好审视一下。就像方才我提到的反射带来的消极影响，使用字节码操纵所带来的痛苦可能是反射的好几倍之多。

更糟糕的是在编译期你根本就看不到可执行的代码。从本质上来说，你不知道产品中实际运行的是什么代码。因此在面对运行期的问题以及调试时，你要花费更多的时间。

ThreadLocal：看到业务代码中如果出现ThreadLocal会让我感到颤抖，原因有二。首先，借助于ThreadLocal，你可以不必显式通过方法调用就可以传递变量，而且会对这种做法上瘾。在某些情况下这么做可能是合理的，不过如果不小心，那么我可以保证最后代码中会出现大量意想不到的依赖。

第二个原因与我每天的工作有关。将数据存储在ThreadLocal中很容易造成内存泄漏，至少我所看到的十个永久代泄漏中就有一个是由过量使用ThreadLocal导致的。连同类加载器及线程池的使用，“java.lang.OutOfMemoryError:Permgen space”就在不远处等着你呢。

类加载器：首先，类加载器是个很复杂的东西。你必须首先理解他们，包括层次关系、委托机制以及类缓存等等。即便你觉得自己已经精通了类加载器，一开始使用时还是会出现各种各样的问题，很可能会导致类加载器泄漏问题。因此，我建议大家还是将类加载器留给应用服务器使用吧。

弱引用与软引用：关于弱引用与软引用，你是不是只知道他们是什么以及简单的使用方式而已？现在的你对Java内核有了更好的理解，那会不会使用软引用重写所有的缓存呢？这么做可不太好，可不能手里有锤子就到处找鼓敲吧。

你可能很想知道我为什么说缓存不太适用使用软引用吧。毕竟，使用软引用来构建缓存可以很好地说明将某些复杂性委托给GC来完成而不是自己去实现这一准则。

下面来举个例子吧。你使用软引用构建了一个缓存，这样当内存行将耗尽时，GC会介入并开始清理。但现在你根本就无法控制哪些对象会从缓存中删除，很有可能在下一次缓存中不再有这个对象时重新创建一次。如果内存还是很紧张，又触发GC执行了一次清理，那么很有可能会出现一个死循环，应用会占用大量CPU时间，Full GC也会不断执行。

Sockets：java.net.Socket简直太难使用了。我认为它的缺陷归根结底源自其阻塞的本质。在编写具有Web前端的典型的Java EE应用时，你需要高度的并发性来支持大量的用户访问。这时你最不想发生的事情就是让可伸缩性不那么好的线程池呆在那儿，等待着阻塞的Sockets。

现在已经出现了非常棒的第三方库来解决这些问题，别自己写了，尝试一下Netty吧。

各位读者，Java出现至今经历了多次版本更迭，每次也都会有诸多新特性的加入。在日常的Java开发中，你认为存在哪些Java特性是很容易导致问题的呢？作者提到不建议在普通的应用开发中使用反射，不过对于一些框架或库的开发，离开反射实际上是无法实现的，例如Spring、Struts2等框架，那么在一般的Java项目开发中，你觉得哪些地方有使用反射的必要呢？换句话说，如果不使用反射就实现不了功能或是需求。文中作者也不建议使用字节码操纵，实际上一些框架在实现某些功能时是必须要使用的，比如说Spring在实现AOP时就使用了Java的动态代理与CGLib库两种方式来达成的。那么对于一般的Java项目来说，哪些地方需要用到字节码操纵呢？欢迎各位读者畅所欲言，一起讨论这些有趣的话题。

赞