推荐最新

Vue 中 vuex 内存泄露问题如何处理？

关于 vue 内存泄露问题? 我有 A B 两个页面,互相切换(未使用 "keep-alive") 发现在 B 页面,会有内存泄露的问题看下大致代码 * B.vuemounted () { const list = [...this.$store.state.list] list.push({ vm: this }) this.$store.dispatch('updateList', list) } 问题原因应该是, 把当前 vue 实例 push 到了 store,导致数组劫持了 this 的引用我的解决方案如下 * B.vuemounted () { const list = [...this.$store.state.list] list.push({ vm: this }) this.$store.dispatch('updateList', list) }, beforeDestroy () { const list = this.$store.state.list const index = list.findIndex(item => item.vm === this) if (index !== -1) { list.splice(index, 1) } this.$store.dispatch('updateList', list) } "image.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/c/user/20240926/40903a79b1a89b97879e949dcad3603a.png) 这样能成功释放内存,我用 chrome devtools 手动回收后, DOM 节点也能成功降下来 "511" 但是后来发现说不要直接操作 store 所以我改成了下面的形式 * B.vuemounted () { const list = [...this.$store.state.list] list.push({ vm: this }) this.$store.dispatch('updateList', list) }, beforeDestroy () { this.$store.dispatch('spliceVm', this) }, * store.jsmutations: { SET_LIST (state, data) { state.list = data }, SPLICE_VM (state, vm) { const list = state.list const index = list.findIndex(item => item.vm === vm) if (index !== -1) { list.splice(index, 1) } state.list = list } }, actions: { spliceVm ({ commit }, data) { commit('SPLICE_VM', data) }, updateList ({ commit }, data) { commit('SET_LIST', data) } }, 这样却释放不了内存,DOM 节点也在持续上升到了"557", 请问我问题出在哪里? "image.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/c/user/20240926/0b957274c8c372e4e58b02e898b4fd77.png)

浏览量207

米小米会努力

内存泄漏怎么排查到具体代码？

切换页面之后发现内存一直在增长，应该是内存泄漏了，拍了快照想追踪是哪里内存没有被回收掉，但是不知道该怎么去看。如下图图一，是不是“保留的大小”这一列占据比例越大说明越说明内存没有被释放？排名第一的是Object是不是说明有很多变量没有被回收？但是打开Object，如下图图二，下面的所有Object又都是0%，这是代表都被回收了？那为什么上方总的Object是7%啊，不太明白 "image.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/c/user/20240927/176fad2eedfbe78b7156da7b2907de09.png) "image.png" (https://wmprod.oss-cn-shanghai.aliyuncs.com/c/user/20240927/a3662cfb16090481815605686f18d415.png) 我拍快照是首先点一下垃圾回收按钮，然后在A页面点开始快照拍一张，然后再切换到B页面，再拍一张快照，不知道这种拍快照方式是不是对的？另外页面切换有几十兆的内存增长是正常的吗？

浏览量122

走你啊啊啊啊啊

Java程序在不同架构的CPU上面出现内存泄漏问题？

使用到的是openjfx来做界面，出现的问题是，在同个系统，同个版本的jdk和openjfx，同个程序，在arm上就内存泄漏，在x86上面就正常的问题，这大概率可能是哪里的问题呢？用的是UOS桌面系统专业版。

浏览量18

爱打瞌睡的三角龙

关于 JVM Class被回收卸载的问题？

问题的背景是我看到了这篇文章： "https://zhuanlan.zhihu.com/p/146410261" (https://link.segmentfault.com/?enc=RyvEA0WIa1k1OWgHZ3vA8g%3D%3D.eUjeTVjmIonZiPCirsBzotjfFDqcsUeqt96utNqqz%2BWEMbfeFDn1Zq%2BD9dE4wyfW) 提到强引用链： thread -> threadLocalMap -> counter -> MyCounter.class -> WebappClassLocader ，导致WebappClassLoader泄漏。对这个有疑问。 Class类型被卸载的条件 "图片" (https://wmlx-new-image.oss-cn-shanghai.aliyuncs.com/images/20241106/b686f6a0b00cfb3e92c42c2705049525.png) 疑问点是其中第二点：加载该类的类加载被回收，是指类加载器对象被gc。假设MyCounter.class 由 WebAppClassLoader加载，那么通过MyCounter.class.getClassLoader() 就可以得到WebAppClassLoader，而WebAppClalssLoader 被gc的条件必然是没有任何人引用她，所以如何做到MyCounter.class 不会引用WebAppClassLoader? 否则是不是就会出现 WebAppClassLoader一直被MyCounter.class所引用呢？如果一直被引用的话那么WebAppClassLoader对象就不会被gc，那么MyCounter.class对象自然也不会被gc了。感觉是鸡生蛋蛋生鸡的问题。如果说 MyCounter.class 对 WebAppClassLoader对象有强引用， WebAppClassLoader对象又怎么可能会被回收呢。如果WebAppClassLoader对象不被gc，那么MyCOunter.class又怎么会被回收呢？ b

浏览量17