Thisisverylikelytocreateamemoryleak.Stacktrac。。。
1、问题描述
启动tomcat部署项⽬时，报This is very likely to create a memory leak. Stack trace of thread错误。
29-May-2018 12:30:09.322 SEVERE [localhost-startStop-1] org.StandardContext.startInternal One or more Filters failed to start. Full details will be found in the appropriate container log file
29-May-2018 12:30:09.323 SEVERE [localhost-startStop-1] org.StandardContext.startInternal Context [] startup failed due to previous errors
29-May-2018 12:30:09.427 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [ROOT] registered the JDBC driver [com.alibaba.druid.proxy.DruidDriver] but failed to un 29-May-2018 12:30:09.427 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [ROOT] registered the JDBC driver [sql.jdbc.Driver] but failed to unregister it wh 29-May-2018
12:30:09.428 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc The web application [ROOT] registered the JDBC driver [org.h2.Driver] but failed to unregister it when the we 29-May-2018 12:30:09.428 WARNING [localhost-startStop-1] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [Abandoned connection cleanup thr  java.lang.Object.wait(Native Method)
ve(ReferenceQueue.java:143)
urrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
urrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)
2、问题原因
tomcat启动奔溃，同时释放了jdbc连接。
3、解决⽅案
这种异常造成的原因千奇百怪，并没有统⼀的处理⽅案，以下是我遇到的不同情况采取的⼏种解决⽅案。
3.1、存在多个tomcat⼦线程
启动前tomcat意外退出，使⽤ps -ef | grep "tomcat名称"查看是不是有多个tomcat在启动，若有，Kill掉。
3.2、调整JVM参数
JAVA_OPTS='-server -Xms5120m -Xmx10240m -XX:PermSize=256m -XX:MaxNewSize=256m -XX:MaxPermSize=5120m '
3.3、去掉tomcat监听
tomcat 6.025以后引⼊了内存泄露侦测，对于垃圾回收不能处理的对像，它就会做⽇志。去掉监听的⽅法也很简单：
在tomcat的l⽂件中，把
<!-- Prevent memory leaks due to use of particular java/javax APIs-->
<Listener className="org.JreMemoryLeakPreventionListener"/>这个监听给关了。
3.4、其他
如果以上⽅案⽆法解决问题，只能逐步排查，排查⽅案如下：
1.使⽤“之前部署正常的分⽀”(我们记为hoaven分⽀)部署项⽬；
2.若tomcat能正常启动，说明tomcat或服务器没有问题，检查⾃⼰的代码；
3.逐步检查⾃⼰的代码：从hoaven分⽀checkout⼀个分⽀(fixbug)，然后将⾃⼰写的代码⼀点⼀点移⾄fixbug分⽀。
4.每移动⼀次代码，部署⼀次，若正常启动，继续移动代码；若报出以上错误，停⽌移动，检查本次移动的代码。
其实3.4⽅法很有效，特别是检查⾁眼⽆法明了的莫名其妙的的bug。
记录下我某⼀次检查以上bug采⽤的3.4⽅案，得出的结果：
代码中，有⼀处注⼊报错很奇怪：
@Slf4j
@Component
public class RestAuthFilter extends FormAuthenticationFilter {
@Resource
MobileDeviceService mobileDeviceService;
@Resource
UserService userService;
...
}
@Slf4j
@Service
public class MobileDeviceServiceImpl implements MobileDeviceService {
@Resource
IHddBaseService hddBaseService;
resource和autowired注解的区别...
}
MobileDeviceService和UserService上的@Resource改为@Autowired部署则没有问题，思考⼀下：@Resource属于jdk的注解，@Autowired属于spring的注解，应该是注⼊
RestAuthFilter时，在spring容器中没有到MobileDeviceService和UserService的实例，@Resource会强制将MobileDeviceService和UserService注⼊进来，⽽@Autowired采
取的措施是不注⼊(或注⼊null)。这样⼀来，就会有新的问题，MobileDeviceService和UserService实
例为null，解决⽅案在后⾯的博客解决。
原⽂地址:blog.csdn/hehuanchun0311/article/details/80506176

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。