有没有办法有选择地调试 JVM 中的单个应用程序（或几个应用程序）？
当我在调试模式下启动 JVM 时，速度自然会变慢。
有没有办法表明我只对调试单个应用程序感兴趣，而不是调试在此 JVM 上运行的 15 个（此处为一个数字）应用程序。
促进这一点的方法可能会使事情变得更快，特别是当我们已经从日志和其他跟踪设施中知道单个应用程序可能出现的问题时，
感谢想法和评论，
谢谢 曼鲁
When i start a JVM in debug mode things naturally slow down.
Is there a way to state that i am interested in only debugging a single application instead of the 15 (making up a number here) applications that run on this JVM.
An approach that facilitates this might make things faster particularly when we already know from the logs and other trace facilities that the likely issue with a single application
Appreciate thoughts and comments
Thanks
Manglu
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我将在这里做出很多假设，特别是当你的问题缺少很多上下文信息时。
首先，我假设您正在尝试在生产中执行此操作。如果是这样，请退一步思考可能会出现什么问题。您可能会放置一个断点，但这会将到达该断点的所有请求排队，通过这样做，您可以将任何 SLA 要求抛到窗外。而且，如果您的应用程序正在处理任何敏感数据，那么您一定看到了一些不应该看到的内容。
其次，即使您是在共享开发或测试环境中执行此操作，这也是一个坏主意。特别是如果不确定您在寻找什么。如果您正在寻找同步错误，那么这可能是错误的方法；其他线程显然会共享您正在读取的数据，并使其不太可能找到罪魁祸首。
最好的替代方法是在应用程序中打开跟踪日志记录。当然，这将是无用的，除非您在应用程序中嵌入了适当的记录器调用（特别是跟踪方法参数和返回值）。有了可用的跟踪日志，您应该能够创建集成或单元测试，以重现本地开发人员安装的确切故障条件；这是您应该进行调试的地方。有时，甚至功能测试就足够了。
一般来说，没有更快的方法，因为它并不适用于所有情况。您可以在任何其他环境中建立选定数量的断点，但这根本不值得麻烦，除非您知道只有您的请求被调试进程拦截。
I am going to make a lot of assumptions here, especially as your question is missing a lot of contextual information.
Firstly, I will assume that you are attempting to do this in production. If so, step back and think what could go wrong. You might be putting a single breakpoint, but that will queue up all the requests arriving at that breakpoint, and by doing so you've thrown any SLA requirements out of the window. And, if your application is handling any sensitive data, you must have seen something that you were not supposed to be seeing.
Secondly, even if you were doing this on a shared development or testing environment this is a bad idea. Especially if are unsure of what you are looking for. If you are hunting a synchronization bug, then this is possibly the wrong way to do so; other threads will obviously be sharing data that you are reading and make it less likely to find the culprit.
The best alternative to this is to switch on trace logging in your application. This will, of course be useless, unless you have embedded the appropriate logger calls in your application (especially to trace method arguments and return values). With trace logs at your disposal, you should be able to create an integration or unit test that will reproduce the exact conditions of failure on your local developer installation; this is where you ought to be doing your debugging. Sometimes, even a functional test will suffice.
There is no faster approach in general, as it is simply not applicable to all situations. It is possible for you to establish a selected number of breakpoints in any of the other environments, but it simply isn't worth the trouble, unless you know that only your requests are being intercepted by the debuggee process.