java线程死锁与内存溢出

跟死锁无关。新手贴，鉴定完毕。

解决问题的方法值得借鉴.
制造问题的手法就要批判了.
1.要用开源的久经考验的成熟产品,不用自己制造'残品'
2.你的代码质量有待提高,该封装的没封装.
3.注意区分线程安全,线程兼容和非线程安全.

建议ＬＺ将你那个代码重构下。
问题多多。
就象repsihWDX同学写的:
无finally,不关连接。try中的东西出异常你的这个connection费了。
还有连接池应该是线程安全的吧！！！

如果我就要在这段代码的基础上改的话该如何修改呢？？请大家给出代码示例(在Data的基础上),真心请教！谢谢！

其实我倒是觉得重复制造下轮子未尝不可。要实现合适自己的连接池，参考开源的实现呗，源码拿着慢慢啃。。。

多线程时候的单例如下：

public static DDConnectionBroker broker = null;
public static final Objcet lock = new Object();
...
synchronized (lock) {
    if (broker == null) {
        broker = new DDConnectionBroker(...);
    }
}
...

Data对象是单例，其中又包含一个Connection Conn和Statement stmt。岂不是全局就维护了一个Connection和Statement的状态？这样张三在关闭连接的时候却把李四的连接关闭了-因为李四的链接最后被创建。

关闭也是个大问题，如果在关闭Statement的时候有任何异常，Connection就关闭不了了。

不知道是你的老板胆大还是你的客户胆大，这样的代码都敢放到production中去。

先不说别的，你写的代码很不专业：

1. 命名不符合java习惯。这个Data给我的感觉是由相当多的人一起写的，风格很不统一。名字取得相当随意，Data像是做数据库操作的类吗？
2. 异常处理存在很大问题，在这么底层就把所有的异常给吃掉了。
3. 滥用实例变量。

总之，基础还太差，Java没有学习一个月就开始做项目了吧。

 

 

将getConnection()和connClose()加上synchronized就能够解决问题吗？Data中有这么多实例变量(connection, stat)，居然还把它做单例，真是不可思议！一个线程关闭的连接可能是由另一个线程所打开的。真不知道你这样做是怎么控制事务的？如果这样修改，我觉得问题仍然没有解决，只是可能你暂时还没有发现而已。

 

我建议是：

1. 不将Data做成单例。
2. 或者将connection, stat实例变量从Data中移去，每次执行数据库操作时就打开连接，完成时关闭连接。这种方式是我推荐的，对现存代码影响最小。

 

还要更加努力的学习，切忌浮躁！

痛定思痛！我决定在每次调用Data时都去new一个，不做单例，可能修改起来工作量有点大。 但是我想问的问题是：是什么原因造成了图片1中内存突然上升和图片2中大量线程死锁的现象的？？？ 我的解释还是因为线程死锁而导致的内存突然上升。有谁能为图片中的现象给出更合理的解释吗？

传说中的连接池会比较好吧？一直打开关闭也不是个办法。。。。现存代码该重构的就重构咯……