weibocom
motan rpc代理是否有javassist实现的计划
比如说dubbo是支持多种方式，jdk动态代理，javassist都支持。
这个需求点触发场景： 我们在调研skywalking探针，发现referer启动后耗费大量native memory，参见：https://github.com/apache/incubator-skywalking/issues/1666
非常想了解微博是否有这个开源计划。
你提到的问题场景中，motan使用的哪个版本？是否使用了
compressMotan协议？
我们使用的是motan1.1.1, 没有显示声明compressMotan，使用的默认值，这个默认值怎么设置呢？配置清单里貌似没有。
比如说dubbo是支持多种方式，jdk动态代理，javassist都支持。
这个需求点触发场景： 我们在调研skywalking探针，发现referer启动后耗费大量native memory，参见：apache/incubator-skywalking#1666
这个问题的触发点是： 我们在k8s管理的docker容器实例里启动app, docker容器内存上线是1.5G，开xms=500M, xmx=1024M。
在不使用skywalking-agent情况下可以启动并且正常运行，但如果加上skywalking-agent后启动容器实例直接被K8S kill，超过了容器物理内存上限。但是如果物理内存开大，比如2.5G，还是同样的jvm参数，即使开启skywalking-agent，也正常，只是top res会高。
当然我们给docker容器的内存上限加大点内存就可以了。但是我想知道这是由哪个点引起的，现在有多个疑点但是不确认是哪个。
只是通过gperftools分析的时候发现gzip相关的native调用有大幅提升，大概升了70~100%左右的样子。
我们以前碰到过这样的问题，是使用new GZIPInputStream(InputStream in)时，如果InputStream中的data不是gzip时，会先创建Inflater，然后在抛出异常，这时创建的Inflater会在finalizer中回收，回收的时间是不确定的，会造成堆外内存占用过大的问题。
你可以看看是不是也是类似的场景
我们以前碰到过这样的问题，是使用
new GZIPInputStream(InputStream in)时，如果InputStream中的data不是gzip时，会先创建Inflater，然后在抛出异常，这时创建的Inflater会在finalizer中回收，回收的时间是不确定的，会造成堆外内存占用过大的问题。你可以看看是不是也是类似的场景
对对，是这个，这个咋解决啊。
我们是在调用new GZIPInputStream前先简单check了一下gzip的magicnum，可以解决大部分的问题，不过不太优雅。
我觉得这个问题由GZIPInputStream的构造方法在异常时回收已创建的对象比较合理
在不使用skywalking-agent情况下可以启动并且正常运行，但如果加上skywalking-agent后启动容器实例直接被K8S kill，超过了容器物理内存上限。但是如果物理内存开大，比如2.5G，还是同样的jvm参数，即使开启skywalking-agent，也正常，只是top res会高。
也就是说，当和skywalking-agent配合使用时，出现的kill现象的原因： 很有可能是skywalking或者引用的相关包存在大量使用gzipinputstrem的情况，没有做gzip格式校验，而触发底层native call.
skywalking的code里没有直接使用gzip，不确定mvn import有没有；引用的相关包里肯定有，因为gperftools有打印。
非常感谢~
