如何知道 spring 生成的 bean 中的 bug 行？
我有一个使用 Spring 和 jpa （由 hibernate）构建的网站。我遇到了错误，但我不知道如何识别错误出现的行。
我无法在我的IDE上调试它，因为它是实时版本（在本地一切运行良好）。
我有日志说： o
rg.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)#012#011
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)#012#011
at com.mycompany.server.rpc.UserService$$EnhancerByCGLIB$$64ed2d4f.createAccount(<generated>)#012#011
at com.mycompany.server.rpc.ServiceRPCImpl.createAccount(ServiceRPCImpl.java:309)
我的问题是第三行。由于 UserService 对象是由 Spring 处理的，因此它变成了代理，我无法知道错误所在。
你知道如何解决这个问题吗？
谢谢
I've got a website build with Spring and jpa (by hibernate). I've got a bug and I don't know how to identify the line where the bug appears.
I can't debug it on my ide because it's a live version (all runs fine in local).
I've got log which says:
o
rg.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)#012#011
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:625)#012#011
at com.mycompany.server.rpc.UserService$EnhancerByCGLIB$64ed2d4f.createAccount(<generated>)#012#011
at com.mycompany.server.rpc.ServiceRPCImpl.createAccount(ServiceRPCImpl.java:309)
My problem is the third line. As the UserService object is handled by Spring, it becomes a proxy and I can't know the line of the bug.
Do you know how to solve the problem ?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
能不能把cglib代理改成jdk代理？ (Spring AOP代理参考）
基本上：如果您将bean作为接口访问，则可以使用jdk代理（spring默认机制），从而保持底层对象完整并获得对堆栈跟踪中的行号的访问。
Is it possible for you to change from cglib to jdk proxy? (Spring AOP proxy reference)
Basically: if you access your beans as interfaces, you can use jdk proxies (spring default mechanism), thereby leaving the underlying object intact and gaining access to line numbers in stack traces.
我想说的是，无法在本地重现这一点是一个重大限制。我会尝试设置您的本地环境或测试服务器来重现问题，使用 JMeter 或其他负载测试软件来模拟并发用户访问的负载。完成此操作后，您的调整/编译/测试周期就会变得更短，并且您可以进行实验性更改，而不必担心中断生产服务器上的服务。这可能看起来需要付出很大的努力，但这项工作不仅会为这个错误带来回报，还会为您将来可能遇到的错误带来回报。
听起来这可能是一个线程错误，特别是因为 spring 默认使用单例范围。考虑到这一点，请考虑为失败的服务创建多线程集成测试。通过负载测试重现错误后，您可以通过使主服务方法
同步来验证它是否是线程错误，从而防止并发使用。如果错误消失，则很可能是并发错误。至于查找错误所在行 - 由于生成了代码，因此没有要查找的行。您能做的最好的事情就是在 UserService 周围的建议中使用的所有 bean 中添加防御性检查。 （例如，检查由于缺少注入而导致的空值。）bean 上的
init-method属性对于执行检查以确保 bean 已完全构造并且所有必需的协作者已设置非常有用。I would say that not being able to reproduce this locally is a significant restraint. I would try to set up your local environment or a test server to reproduce the problem, using JMeter or other load test software to simulate load of concurrent user accesses. Once this is done, your tweak/compile/test cycle becomes a lot shorter, and you can make experimental changes without fear of disrupting service on your production server. It may seem like a lot of effort, but the work will pay dividends not just for this bug, but for bugs you may encounter in future.
It sounds like it could be a threading bug, especially since spring by default uses singleton scope. With that in mind, look into creating multithreaded integration tests for the service that is failing. Once you have reproduced the bug through load testing, you can verify that it's a threading bug by making your main service method
synchronized, preventing concurrent use. If the bug disappears, it is most likely a concurrency bug.As to finding the line of the bug - there is no line to look for since the code is generated. The best you can do is to add defensive checks in all beans that are being used in the advice around the UserService. (E.g. check for null values due to missing injections.) The
init-methodattribute on beans is useful for performing checks that the bean has been fully constructed and all required collaborators have been set.如果您无法在本地环境中重现该问题，则可能是与环境/网络相关的问题。我首先会在测试环境（更接近生产环境而不仅仅是自己的本地计算机）中重新创建问题来调试错误。
您还可以使用 Fiddler 调试实时版本的网络相关问题。
If you cannot reproduce the issue in local environment, then may be it is environment / network related issue. I would first recreate the issue in test environment ( which is closer to production environment and not just own local machine ) to debug the bug.
You may also use Fiddler to debug network related issues for a live version.