关于一次内存调优的处理

大体说一下场景吧，是一个CS系统的GUI程序，用javaFx来进行处理，需要展示svg文件，由于java这个领域用batik是一个比较好的选择，所以我就用batik来进行svg的展示，但遗憾的时batik是通过swing的g2d来进行刷新展示的，javafx领域没有特别官方的方式来进行svg展示，但好消息是javafx可以将swing的jpanel之类的程序作为自己的一个小控件来进行集成。

正如你看到的，这个页面是个tab，可以关闭。里面这些花花绿绿的，是svg文件通过batik渲染后的一个swing的panel，被放在了javaFx的tab页面中。

我们的问题是：多次打开这一页面，上次的实例及线程都不回收，下面我们来看一下，如何定位及解决这个问题。

一、内存问题：

最上面的一行是内存，我每开一次tab页面，可以看到，蓝色区域会像楼梯一样，一直增加，后面有个下楼梯的地方，是因为我手动执行了GC，可以看到内存被吃住了，不会下来了，一直就这行占着了。

遇到这种情况，首先分析自己的程序，不要怀疑别人，几乎可以肯定是你自己的问题。

针对我们当前的程序，打开tab的页面是一个类，叫StationNetworkController，这是一个javafx中常见的类，主要是用来进行页面上数据的处理之类的。首先去代码里看一下，我们的svg中对应的实例是StationNetworkController$1，对的，这是一个内部匿名类。我们首先看一下jvm中的实例个数，当前，我们已经把所有的页面都关掉了，我们看一下：

可以看到了4个，肯定是不对的，我们已经关掉了页面，按常理应该是0个才对，下面我们就分析一下这几个实例为什么迟迟不能被回收。选中这一条，然后右键，-> show selection in heap walker，然后会进入一个jvm内存的抓取，然后就可以对这几个实例进行分析了，如下图：

看到了，这四个对象都被抓出来了，然后选中其中一个，右键，->show in graph，就会进入下图：

下一步怎么办，最重要的一步：在蓝色的项上右键，-> show path to GC root，然后就可以看到这个实例为何不能被回收，当然不是那么明显，需要你结合代码进一步进行处理，点击后的效果：

对，从最开始的黄色开如，一路下来，就可以看到这个类为什么不会被回收，针对我们的情况：

这么几句，针对我们的代码，怀疑下述可能有问题：

所以，可以初步分析是，layout牵住了我们的svg展示的canvas(JComponent，swing的)，而layout是另一个JPanel的，所以如果我们斩断imagePanel的相关联系，是不是会好一些，以下是我加在TabClose回调中的代码：

所以此处可以看到JavaFx虽然宣称可以集成Swing中的组件，但是还是有许多地方需要自己注意一下，灵活控制你的实例 ，不要泄漏内存。

加了这一段后，会好很多，内存问题会很好的解决，一并列一下上面的canva.release()的代码，以方便遇到同样问题的同业们：

batik中，stopProcessing这一句很重要，会关掉UpdateManager的线程，这个挺重要的，请一并考虑一下。

 

思考一下：

为什么我们在进行BS编程的时候，没有这么多的问题？是不是可以回想一下request进来后，在一个线程中处理，而且在企业级开发中，BS的开发套路要固定的多，如无状态的service, dao, 渲染是通过html直接在response中返回，一个请求处理完成后，几乎所有的与此请求相关的对象都会自动脱离jvm的root，当然除了那些可复用的无状态的service这类的东西。

所以为什么CS的开发，会多少有些不为人看重，是有原因的，比较麻烦，对程序员要求也多了几项技能，线程，内存模型，还有一些小众的gui开发技术（swing,javafx等）。

同时，我们也可喜的看到，通过BS的技术来进行CS的GUI开发的一些技术，如NW,Electron等，其实这都是一些好的方面，如果想开发一套，运行稳定的CS的程序，确实要付出更多的努力，但也给你更大的自由。

零零散散说到这里吧，对了，上面我用的工具是JProfiler，是个很好的jvm分析工具，大家可以试一下。