静态方法会导致内存泄漏吗?

问题描述

我喜欢把一些常用的或者公共方法放到一个工具类里,写成静态(static)的形式,方便调用,但是如果这个方法需要传递一个参数(外部短生命周期对象的引用)的话,会不会造成内存泄漏啊?比如:public static void getXXX(Object o){ .....}这种写法用多了会造成内存泄漏吗?还是只有短周期对象引用一个静态变量时才会导致?一个是短生命周期的对象持有静态,也就是不销毁的变量,这个我能理解。但是把短生命周期对象引用传递给一个静态方法,我就凌乱了...系统初始化静态方法的时候,这个短生命周期对象还没传递进去啊?它们之间到底是什么关系呢?求科普,求解释... 问题补充:boy00fly 写道

解决方案

引用这种写法用多了会造成内存泄漏吗?这种写法不会造成内存泄漏。为什么不会呢?要想造成内存泄漏,你的工具类对象本身要持有指向传入对象的引用才行!但是当你的业务方法调用工具类的静态方法时,会生产一个称为方法栈帧的东西(每次方法调用,JVM都会生成一个方法栈帧),当方法调用结束返回的时候,当前方法栈帧就已经被弹出了并且被释放掉了。 整个过程结束时,工具类对象本身并不会持有传入对象的引用。引用一个是短生命周期的对象持有静态,也就是不销毁的变量,这个我能理解。 但是把短生命周期对象引用传递给一个静态方法,我就凌乱了... 不要凌乱 ,把对象引用传递给静态方法(不是静态方法也是一样的),在调用结束时,工具类对象本身并不会引用传入的对象。所以就没有问题。可参考http://boy00fly.iteye.com/blog/1096637
解决方案二:
不会的, 但是不是好习惯. 如果你觉得有地方必须写静态方法(main~~~),我觉得你该想想是不是自己的思路出问题了. 系统会直接给静态方法分配内存.一直到程序运行结束内存才会被释放. 使用方法时对象被传递,不使用不传递.但愿我的话你能看懂. 语文不好的说~
解决方案三:
去查一下关于变量的作用域,即GC的一些基础知识

时间: 2024-11-08 22:31:45

静态方法会导致内存泄漏吗?的相关文章

Android中导致内存泄漏的竟然是它----Dialog

一. 内存泄漏的 Bug 猛增 最近在 App 进行 mokey 测试的时候检测到一些内存泄漏问题.在前天的测试中,楼主一瞬间收到了4个这样的 Bug 单,瞬间心理无比纠结,真有千万只羊驼向我奔来. 登录页面出现内存泄漏??!!楼主的代码是如此的完美而无懈可击,这么可能出现这么多泄漏的问题? 插播什么是 Activity 泄漏:Android 中 Activity 代表一个页面,拥有一段生命周期,生命周期结束后,Activity 对象应当在之后某个合适的时机被 VM 回收内存.出现了泄漏就意味着

未释放事件Handler可能导致内存泄漏

以前曾看见过这样一个问题:托管代码会不会导致内存泄漏.自己对GC的了解也不是很深,但还是比较赞成这样的观点:托管代码不会产生内存泄漏,除非你没有正确释放非托管资源. 今天看到一个非常有趣的例子,关于没有释放事件的Handler导致的内存泄漏. 以前对于释放Handler的观念是一点也没有,这主要因为没此方面的意识,没有养成好的习惯.只知道当关心这个事件的时候就注册一下, 暂时不关心了就移除掉.却从来没有想到最终不移除不必要的Handler会导致此类无法被正常回收,导致不必要的内存浪费. 事情是这

eventbus-Activity中用EventBus的onEventAsync方法做耗时操作会不会导致内存泄漏?

问题描述 Activity中用EventBus的onEventAsync方法做耗时操作会不会导致内存泄漏? 如主题所述,如果在onEventAsync中做耗时操作,这个时候关闭了Activity会不会导致内存泄漏,如果关闭之后又立即启动该Activity又会是怎么样的? 解决方案 这个没法准确答,若果Activity已经结束,但耗时操作仍然持有Activty的变量啦,控件啦等等,那肯定会出问题.建议,Activity关闭的工作放在onEventAsyn结束之后处理.

WMQMessageConsumer构造函数抛JMSException导致的WMQFFSTInfo内存泄漏

问题描述 公司基于IBMMQ开发了企业级综合服务管理平台(ESB),同时将用户.客户.机构等等基础信息管理功能分离出来提供基本的数据服务,而其他系统则通过综合服务管理平台进行服务访问.我方恰好设计.并开发了其中的用户信息管理系统.该系统需要管理企业范围内的所有用户信息.机构信息.系统信息.功能信息.权限信息,并提供各种用户认证服务.其中一个较为关键的功能是,我们需要将各业务系统相关的用户.机构以及功能权信息实时同步到各业务系统,并且保证同步功能的高效.稳定与可靠.数据信息实时同步功能,依托企业级

Java中关于内存泄漏出现的原因汇总及如何避免内存泄漏(超详细版)_java

Android 内存泄漏总结 内存管理的目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题.内存泄漏大家都不陌生了,简单粗俗的讲,就是该被释放的对象没有释放,一直被某个或某些实例所持有却不再被使用导致 GC 不能回收.最近自己阅读了大量相关的文档资料,打算做个 总结 沉淀下来跟大家一起分享和学习,也给自己一个警示,以后 coding 时怎么避免这些情况,提高应用的体验和质量. 我会从 java 内存泄漏的基础知识开始,并通过具体例子来说明 Android 引起内存泄漏的各种原因,以

linux下创建线程内存泄漏,php的json

  这次还是把遇到的几个问题整理一下,希望再遇到的同学能轻松解决.另外最近博客的feeds延迟更新的原因也会一起说明一下. 1.linux下创建线程导致内存泄漏 今天在外网发布了一个server之后,用top发现virt的使用量一直在涨,而且一次涨8m.于是可以断定有内存泄漏了,经过排查,最终确定原因出在多线程的问题上: 代码如下: 1 2 3 4 5 6 pthread_t thread_id; int ret=pthread_create(&thread_id, NULL, flush_th

Java中用软引用阻止内存泄漏

在本文中,他将解释 Reference 对象的另外一种形式,即软引用(soft references),用于帮助垃圾收集器管理内存使用和消除潜在的内存泄漏. 垃圾收集可以使 Java 程序不会出现内存泄漏,至少对于比较狭窄的 "内存泄漏" 定义来说如此,但是这并不意味着我们可以完全忽略 Java 程序中的对象生存期(lifetime)问题.当我们没有对对象生命周期(lifecycle)引起足够的重视或者破坏了管理对象生命周期的标准机制时,Java 程序中通常就会出现内存泄漏.例如,上一

Android 内存泄漏的几种可能总结

  Java是垃圾回收语言的一种,其优点是开发者无需特意管理内存分配,降低了应用由于局部故障(segmentation fault)导致崩溃,同时防止未释放的内存把堆栈(heap)挤爆的可能,所以写出来的代码更为安全. 不幸的是,在Java中仍存在很多容易导致内存泄漏的逻辑可能(logical leak).如果不小心,你的Android应用很容易浪费掉未释放的内存,最终导致内存用光的错误抛出(out-of-memory,OOM). 一般内存泄漏(traditional memory leak)的

浅析Node.js中的内存泄漏问题

  这篇文章是由Mozilla的Identity团队带来的 A Node.JS Holiday Season系列文章的首篇,该团队上个月发布了 Persona的第一个测试版本.在开发Persona时我们构建了一系列的工具,包括了从调试,到本地化,到依赖管理以及更多的方面.在这一系列的文章中我们将与社区分享我们的经验和这些工具,这对任何想用node.js建立一个高可用性服务的人都很有用.我们希望您能喜欢这些文章,并期待看到您的想法和贡献. 我们将从一篇关于Node.js的实质性问题:内存泄漏的主题