在《Java/J2EE应用Profiler整合：调试类型和调试流程》和《Java/J2EE应用Profiler整合&治理实践挑战》中，列出了在整合调试工具和Java/J2EE应用程序（独立的或者是基于应用服务器的）中一些最常见的实践挑战，在应用程序性能管理流程中探讨调试集成活动，工作区可以明显地帮助减少运转时间需求。下面将提出具体建议和方法。 不可协调的应用程序 问题 在某些情况下，应用程序不是性能的调整或者业务场景具有很高的响应时间，应用程序（应用服务器）和profiler会引起超时，应用服务器有时甚至会不能启动。这是用于调试工具创建字节码编译器的额外开销，方法执行时间的……
我们一直都在努力坚持原创.......请不要一声不吭，就悄悄拿走。
我原创，你原创，我们的内容世界才会更加精彩！
【所有原创内容版权均属TechTarget，欢迎大家转发分享。但未经授权，严禁任何媒体（平面媒体、网络媒体、自媒体等）以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
在《Java/J2EE应用Profiler整合：调试类型和调试流程》和《Java/J2EE应用Profiler整合&治理实践挑战》中，列出了在整合调试工具和Java/J2EE应用程序（独立的或者是基于应用服务器的）中一些最常见的实践挑战，在应用程序性能管理流程中探讨调试集成活动，工作区可以明显地帮助减少运转时间需求。下面将提出具体建议和方法。
不可协调的应用程序
问题
在某些情况下，应用程序不是性能的调整或者业务场景具有很高的响应时间，应用程序（应用服务器）和profiler会引起超时，应用服务器有时甚至会不能启动。这是用于调试工具创建字节码编译器的额外开销，方法执行时间的线性增加的开销，并造成业务场景执行时间的增加，导致超时。
推荐的解决方案
推荐的建议是，确定高延迟的代码组件，“通过引入应用程序中的Java代码，捕获在关键方法中的时间开销。”然而，这种方法有弊端，选择关键的/决定性的类和方法，引用一个业务交易和工具，并记录代码修改和部署的状态。
以下的代码片段说明了这一点。
| 以下是引用片段： Class A { private long startTime, endTime; public Obj obj1; public Obj obj2; void public method1(){ startTime = System.currentTimemillis(); ………. ……….. ……… endTime = System.currentTimemillis(); <logUtility>.log(“Time Spent in method” + this.getClass().getcurrentMethod()+ “in msec:” + (endTime-startTime); //assuming the log utility being used for this as well } |
安全权限
本章着重介绍了典型的安全或者访问权限问题，同时整合Java profiler引擎和Java应用程序。下表列出了问题和建议，以克服这些。
问题 | 问题描述 | 建议 |
引擎安装文件的所有者权限 | 如果用户没有拥有引擎/探头的安装文件的权限，Java进程执行/启动时，由于没有足够的安全权限，不能加载所需的库 | 文件系统上的引擎安装文件件要有“所有者权限”，类似“Java进程”的递归 |
引擎安装文件的执行权限 | 如果引擎文件只有读和写权限，引擎/探头库不能在Java进程中执行 | 用递归方法为探头安装文件夹指定特定的访问权限 |
在Java应用程序/应用程序服务器上启用Java安全 | Java应用程序启用Java安全，由于在server.policyfile 中缺少指令，profiler可能不会启动 | 通过在server.policy中添加下列指令，为Agent/Probe的jar文件授予所有的安全权限 |
例如：当整合HP Diagnostics Java Probe和WAS 6.1时，profiler不能启动，获得所有需要的指标。下面内容添加到server.policy文件中： | ||
（注意：在单独的应用程序中使用Java安全，识别所需的安全指令添加到属性文件中） |
应用程序缓存
问题
对于某些应用程序，缓存（无论是自定义的缓存或是分布式缓存产品）是用来提高应用程序的性能，profiler可能不会如期工作。这是由于在缓存中提高追踪和调试每一个可用对象的开销。
由于一些追踪器和调试器在不同层中有默认的检测点，如JSP/Servlet、EJB、DAO和标准的Java架构，如STRUTS、SPRING，ORM工具，如HIBERNATE，即使没有添加一些自定义的检测点，如果在应用程序下使用巨大的对象缓存，会有很大的开销。
推荐的解决方案
在这种情况下，建议遵循以下两个选项之一：
- 禁用所有默认的检测点，伴随探头/探查，依据Profiler，观察应用程序的变化。
- 当分析应用程序时，禁用缓存，找出Java代码的瓶颈和其他地方，如数据库、外部系统等。
另外，减少缓存的大小，使对象追踪和调试的影响变小（在大多数情况下，缓存的设置是可用的，可以配置它的大小，以及缓存的失效策略）
J2EE服务器中，COTS产品的默认检测
问题
如果应用程序需要调试一些运行在JVM流程上的COTS产品，引用调试引擎，JVM可能不会启动。
我想要和大家分享我的经验，托管在WebSphere应用服务品上，业界领先的规则引擎产品，比如，在整合Java调试器后无法启动。应用程序服务器崩溃的原因是在Java编译程序的libjvm.so库中。Profiler库中没有任何错误。没有profiler，JVM就不会崩溃。
推荐的解决方案
确保运行在Java流程中的COTS产品，默认没有启动调试或者监听机制。如果启用，请停掉，并运行profiler。
检查COTS产品是否兼容profiler - 很多时候，很难得到一些关于遵循产品兼容性的文档。因此，建议找工具厂商或者COTS产品，以获得支持。
待定的操作系统
问题
在某些情况下，基于UNIX操作系统（尤其是UNIX/SOLARIS/LINUX/HP-UX）的文件描述符数量的设置，会影响调试流程。
因为调试活动会加载很多的库和二进制文件，在有探头/探查的情况下，应用程序服务器可能不会启动，正常情况下使用文件描述符极少。
推荐的解决方案
推荐检查当前文件描述符的限制（使用ulimit –n命令），提升系统文件描述符允许的最大值。要注意，每当profiler作用在应用程序中时，这不是要强制更改的命令，然而，在附有profiler应用程序时，在不可预料的情况下，它可以作为检测清单条目之一。
结论
本文想要做一个简短的调试流程，以及整合调试工具和Java应用程序时的特定问题。这里讨论的问题和补救方法是基于我的经验，和不同的Java调试工具、基于web和企业Java/J2EE应用程序，他们将作为性能架构师/工具师的检测清单，帮助他们迅速解决一些profiler问题，减少调试活动的周转时间。
