你没看错，就是这个题目：即使是Java系统也会变成“遗留”系统。每当我们想起遗留系统时，我们就会想起那些存储着大量文件数据并只能用COBOL访问的嘎吱嘎吱作响的大型主机。但事实是，Java已经是一门具有15年历史的开发语言，用Java写就的成千上万的系统已经成功运行了十年甚至更久。
因此，考虑到许多读者都会工作在某个遗留的Java系统上，我根据自己的经验特地攒了这八个技巧，来帮助团队更新和激活他们的遗留Java应用。
技巧1：使用分析器
分析器提供了任何其他工具无法提供的功能，从而能够深入检查你的应用。如果你的应用已经有一年多时间没有被分析过了，那么它肯定会有大块大块的低效代码，潜伏在某个黑暗的角落。市面上有许多不同的或免费或商业的分析器。对于CPU分析，我最喜欢的是JProfiler，因为它足够强大能分析出大多数问题，同时易于设置，尤其当你使用它内建的设置向导的时候。而诊断内存问题时，我最亲睐的工具是Eclipse Memory Analyzer，因为它使用的是记录在磁盘上的索引，而不是把整个堆的快照放到内存中。
通常来说，隐藏着的易耗尽CPU的代码包括低效的hashCode（）或者equals（）方法（在卷动JTable时以及使用Java collection类时，它们会被调用上百万次），以及一些出人意料的出自Sun之手的低效类，比如SimpleDateFormat。
分析器可能会明显地让你的应用变得很慢，所以你一定要在测试环境中使用它。
技巧2：监控数据库使用状况
分析器除了可以显示你的应用过度占用CPU时钟的细节，它们也可以对你的应用在哪些地方长时间做了数据库的操作给出提示。但更好的用来监控数据使用的工具，是像Proactive DBA或者HP Diagnostics，或者任何其他来自于你的数据库产品厂商的工具。这些工具可以告诉你，哪些代码做了长时间的SQL调用，以及哪些代码在短时间内对同一行做了多次调用。来自数据库厂商的工具还可以帮助发现那些阻塞了其他调用的查询；虽然在我的经验里，这样的阻塞问题基本不过是些简单的、低效的SQL用法。
我写了一个新的工具叫做jdbcGrabber，它可以让你以可视化的形式描述出哪些代码正在访问哪些数据表。通过这种可视化呈现，你可以很容易发现那些多次访问数据库中不同部分信息的代码，从而将其调整为一次合并的请求。
技巧3：构建和部署自动化
许多遗留系统缺乏一种完全自动化的方式，来构建它们的代码，更不用说自动部署了。自动化构建和部署对于提高遗留系统开发者的效率来说，是一种简单直接而又低风险的方式，而且通常不需要修改代码。
没有自动化的构建和部署过程，新的开发者不得不重新发明轮子，跟那些前辈们早就斗争过的同样问题重新来斗，而且每次重复的部署问题发生，开发者都会发明出不同的解决方案。
虽然Maven是一款卓越的而且使用广泛的构建工具，但它对你的源码树结构以及库依赖有着固执的要求，所以把它用在遗留应用中会有点困难。但足够优秀的Ant应该更易于使用，因为它处理起遗留代码结构更加灵活，也更容易部分采用，而不是全盘采用。
技巧4：自动化你的操作并使用JMX
另外一种提高遗留应用的效率但不会带来修改代码的风险的方式是，改善它的运维。许多内部开发的企业系统，一般都需要大量出人意料的手把手指导和维护，即使这样是不应该的。
既有的Java功能可以通过使用JMX很容易地暴露给负责运营的人们，而不会带来负面影响。许多开发者对JMX比较熟悉是因为，他们用JMX来跟JBoss和WebLogic这样的应用服务器进行交互，但他们不清楚把JMX用在他们自己的应用中是多么方便。任何Java class都可以通过JMX暴露出来，几乎没什么负面效果，也没有什么风险。
比如，如果你的应用有一个本地的静态HashMap作为cache，你就可以通过JMX来暴露功能，从而很容易地清除那个cache。
一旦应用通过JMX暴露，运维团队或者开发者就可以以良好的方式来操作应用，无需直接访问运行着应用的机器。
技巧5：创建单元测试
一旦你对遗留系统的修改破坏了某个功能，你所面临的最大障碍之一就来到了。一些工具宣称能对代码进行反向工程，并为其创建单元测试，但我对这些工具没有太多的信心。要想有足够的信心，你的单元测试的确覆盖了你期望它们覆盖的代码，你就不得不亲自创建它们。
考试大温馨提示：本内容来源于网络，仅代表作者个人观点，与本站立场无关，仅供您学习交流使用。其中可能有部分文章经过多次转载而造成文章内容缺失、错误或文章作者不详等问题，请您谅解。如有侵犯您的权利，请联系我们，本站会立即予以处理。
编辑推荐：
JavaTimer和TimerTask详解
怎样用Jvm处理Java数组
Java数组之初始化及实例代码
