我对Java世界还很陌生,想知道以下内容是否会引起我周围的任何内存泄漏,请重新分配上下空值.只想确保这不会导致任何内存泄漏,因为那是不好的
import android.graphics.Point;
import android.util.Log;
import android.view.MotionEvent;
public class TouchHandler {
public TouchHandler() {
}
static Point down;
static Point up;
static boolean isUp = false;
static boolean isDown = false;
public static void processEvent(MotionEvent event) {
switch (event.getAction()) {
case MotionEvent.ACTION_DOWN:
Log.i("betterinf", "ACTION DOWN");
down = new Point();
down.x = (int) event.getX();
down.y = (int) event.getY();
isDown = true;
break;
case MotionEvent.ACTION_UP:
Log.i("betterinf", "ACTION UP");
down = new Point();
up.x = (int) event.getX();
up.y = (int) event.getY();
isUp = true;
break;
case MotionEvent.ACTION_MOVE:
break;
}
}
public static void Update(Long deltaTime) {
if (isDown && isUp) {
//event has happened
isDown = false;
isUp = false;
down = null;
up = null;
Point vel = new Point();
vel.x = down.x - up.x;
vel.y = down.y - up.y;
GM.getBallManager().newPlayerBall(down, vel);
}
}
}

参见英文答案 > Java String.substring method potential memory leak?                                    3个
据说String类中的substring方法会导致内存泄漏.这是真的吗？怎么样？有什么替代方案吗？
特别是在寻找答案,在java中可能导致内存泄漏的所有其他事情是什么？这将有助于我在编码时保持谨慎.
解决方法:
在以前版本的JDK中,substring方法的实现将构建一个新的String对象,保持对整个char数组的引用,以避免复制它.因此,您可能无意中仅使用一个字符串保留对非常大的字符数组的引用.这可能导致Here’s an example的错误.
此方法现已更改,此“泄漏”不再存在.
如果你想使用一个旧的JDK(比OpenJDK 7更新,更新6)并且你希望在substring之后拥有最少的字符串,那么使用构造函数取另一个字符串：
String s2 = new String(s1.substring(0,1));
关于你的第二个问题,关于“其他可能导致java中内存泄漏的事情”,不可能以建设性的方式回答.在java标准库中没有很多实例可以很容易地保持对对象的隐藏引用.在一般情况下,请注意您构建的所有引用,可能是未清理的集合或外部资源(文件,数据库事务,本机窗口小部件等)中可能出现的最常见问题.
标签：java,memory,memory-leaks
来源： https://codeday.me/bug/20190926/1818385.html

http://blog.csdn.net/yakihappy/article/details/3979942
会。java导致内存泄露的原因很明确：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。
1.集合类，集合类仅仅有添加元素的方法，而没有相应的删除机制，导致内存被占用。这一点其实也不明确，这个集合类如果仅仅是局部变量，根本不会造成内存泄露，在方法栈退出后就没有引用了会被jvm正常回收。而如果这个集合类是全局性的变量(比如类中的静态属性，全局性的map等即有静态引用或final一直指向它)，那么没有相应的删除机制，很可能导致集合所占用的内存只增不减，因此提供这样的删除机制或者定期清除策略非常必要。
2.单例模式。不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在(以静态变量的方式)，如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露，考虑下面的例子：
class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B类采用单例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}
显然B采用singleton模式，他持有一个A对象的引用，而这个A类的对象将不能被回收。想象下如果A是个比较大的对象或者集合类型会发生什么情况。
上面所讲的这些也启发我们如何去查找内存泄露问题，在代码复审的时候关注长生命周期对象：全局性的集合、单例模式的使用、类的static变量等等。在Java的实现过程中，也要考虑其对象释放，最好的方法是在不使用某对象时，显式地将此对象赋空。最好遵循谁创建谁释放的原则。

内存泄漏：是指对象或者变量没有被引用，却一直占据在内存中，使得这一块内存不能够再被利用起来，造成内存的不可被用称为泄漏。
但是Java中有垃圾回收机制GC，GC能够将不再被使用的对象，自动从内存中清除。

即使这样，Java中也存在着内存泄漏的情况：
一：当长生命周期的对象持有短生命周期的对象引用，就很可能发生内存泄漏。尽管短生命周期的对象已经不再需要，但是长生命周期的对象一直持有他的引用导致其无法被回收。例如，缓存系统；加载一个对象放在缓存系统中，一直不去使用这个对象，但是它一直被缓存引用，所以不会被回收导致缓存泄漏。
检查java中的内存泄漏，一定要将程序各个分支情况都完成执行至结束，然后看其是否被使用过，如果没有才能判定这个对象属于内存泄漏。
二：当一个对象被存储进HashSet集合中，就不可修改这个对象中用于计算哈希值的属性了。否则，对象修改后的哈希值与刚添加进HashSet集合时的哈希值不一样，此时如果将当前对象的引用作为参数，用contaions方法判断对象是否存在，则会返回找不到对象的结果。这会导致无法从HashSet单独删除当前对象，造成内存泄漏。