记 com.sun.jdi.ObjectCollectedException 异常原因。
前些日子接触公司项目代码后，进行debug查看集合中元素内容的时候。经常看着看着还没看完，再看的时候见就看不见内容了。
提示框内显示 com.sun.jdi.ObjectCollectedException 形如下图。
开始遇到这个问题感觉很是奇怪,因为以前debug好好的，怎么这个项目的debug里总是看着看着就没了，百度谷歌搜索异常类名称ObjectCollectedException 也没发现什么资料，几个搜索记录显示可能与垃圾回收有关。
这个异常类在jdi包下，jdi是Java Debug Interface的缩写，是专门用来debug的一些程序，这方面资料也比较少。
既然说可能跟GC有关，那就想办法观察程序GC状态，什么时候进行了GC，以及debug无法查看集合内存放元素时的是否发生了GC以及内存状况。
这里找来了Java VIsualVM工具，JDK自带，双击就能启动还是很方便的。
左侧找到启动的项目进程，右边出现的窗口中，选择Visual GC选项卡(如果没有这个功能，需要从安装相应插件，软件内安装选择菜单栏中 工具-插件 到可用插件中找到安装)，查看当前内存使用和分配情况。
至此以后，对该项目进行debug时，我便开启Java VIsualVM工具进行监控，终于发现，每次debug时，当Eden Space区满了触发GC时，再次查看集合变量时，就无法查看，元素那显示unknown value 下方 显示com.sun.jdi.ObjectCollectedException。
虽然已经确定无法查看集合元素确实垃圾回收弄的，但是为什么我自己一个人在自己电脑测试时内存的Eden Space区总是一直上涨触发GC呢，这个正常吗？
经过多次观察。项目启动后，用Java VIsualVM工具进行监控，即使什么都不做，程序的内存变化是下面这个样子
可以看到Eden Space区域 一直在稳步上涨，到达预定位置就会触发GC，这还是挂机状态的变化。如果对项目系统进行操作的话，程序内部创建对象内存上涨的更快，当然使用系统引起的内存消耗是正常的。
下面使用工具，找出挂机状态下，到底哪部分程序活动频繁，进而确定是哪部分程序消耗了内存。
这里使用抽样器中的CPU 抽样器进行监控。这次遇到的比较简单，不出几秒，就能看出filewatch包下的几个程序排在在上面。
查看名称基本可以断定是SpringBoot下devtools中的功能引起的。
查看该maven工程的pom文件，找到相应依赖引入。(version版本还报黄线 不对应。。)
注了注了。重启项目看看情况。
内存还是慢慢的涨……
抽样器查看，发现devtools居然还在！奇了怪了。明明注释了pom文件中的依赖引用，为何devtools还在运行。
经过查看发现，项目配置中Reference Libraries中还有引用。删除引用。
再次启动项目，进行监控查看。
可以看到这回，项目启动完成后，内存变化已经非常平稳了。
抽样器中也看不到devtools的身影了。
这下就可以愉快的在debug模式下慢慢查看集合中的变量了。
未完待续。。。。