Tidus
Tidus
经过测试。结论如下： 在gson和jackson 默认都是按字段定义顺序来序列化 fastjson版本1.2.73 如果bean 没有getter/setter， 禁用 SerializerFeature.SortField.getMask() 之后，序列化会按照定义顺序。 但如果 bean 有getter/setter，禁用 SerializerFeature.SortField.getMask() 之后，序列化随机乱序。 --- 没有getter/setter 时，TypeUtils.computeGetters():1858 这里获取不到getter方法，然后到2168行获取fields数组。 这里获取fields数组，~~和字段定义顺序是一致的~~。所以序列化出来也会按照定义顺序。 订正： 根据 https://stackoverflow.com/questions/1097807/java-reflection-is-the-order-of-class-fields-and-methods-standardized clazz.getFields() 和clazz.getMethods() 都是无序的。。。 所以这里field和定义顺序一致只是个偶然。 但如果有getter/setter ，代码走到上面这处，根据map遍历结果来决定字段序列化顺序，这导致禁用排序后，每次序列化出来的顺序就是LinkedHashMap的插入顺序。而 这个map插入顺序，是按 clazz.getMethods()...
再补充一下，gson和jackson为什么实现会和字段的定义顺序一致。 基本都是使用了 getDeclaredFields 来作为字段序列化的顺序的 ``` Gson 2.8.6 com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields():152 Field[] fields = raw.getDeclaredFields(); ``` --- ``` jackson-databind-2.11.3 com.fasterxml.jackson.databind.introspect.POJOPropertiesCollector.collectAll():322 - POJOPropertiesCollector._addFields():393 ... - com.fasterxml.jackson.databind.introspect.AnnotatedFieldCollector.collect():48 - com.fasterxml.jackson.databind.introspect.AnnotatedFieldCollector._findFields():73 cls.getDeclaredFields() ```
我开始也出现这个问题。 然后发现如果挂了自己域名的， callback 要填具体的博客域名，而不是默认的xxx.github.io 那个。。。 然后 repo 地址才是写xxx.github.io 就行
@beykery 那么可否这样理解： send 的时候，可以把list 里堆积的消息全部发出去么。 就算更新频率慢些，但发送消息条数应该不会差太多才对。另外更新频率参数我试着修改到 1ms， 数量还是没有明显提高。
noDelay(int nodelay, int interval, int resend, int nc) 这个方法的的 interval 参数，是否就算这个调度时长？ 我是把这个参数。。。额，看到内部代码了，包内部最小设置了是10ms。 那么，C#的原版的代码是否也有这个问题呢，就是互发频率不够高的问题？
https://github.com/skywind3000/kcp 这个啊，kcp的原版。 哦，原版是C++的，记错了
同样出现这个问题， KcpOnUdp.java 202行，导致update 不执行了。 用maven 的1.2.6的版本会出现这个问题，就是 KcpOnUdp 197行， needUpdate ==true，但在flush方法里，updated == 0 直接return了。而时间转为int 变为负数，所以update 也执行不了 而最新源代码，去掉了 updated 的这个判断，所以 可以执行发送了。 但这个修改未发布到最新 maven里
大概找到原因了，首先是默认的Netty 设置，缓冲区不够长，导致发送9000多字节后可能出现丢失。 然后KcpOnUdp.java 的update() 方法，时间戳转换为 int， 导致变成负数。 所以，超时补发也失效了。 希望作者修复这里 时间转为int的bug
Here is the Jmeter log with debug level. It seems that jmeter also got hanged. 2019-08-13 18:06:39,929 DEBUG o.a.j.g.AbstractJMeterGuiComponent: setting element to enabled: true 2019-08-13 18:06:39,929 DEBUG o.a.j.g.GuiPackage: Gui retrieved...
好像是我理解失误， 是bean先执行构造方法的。。。 构造方法的耗时并不统计在。 postProcessBeforeInitialization 和 postProcessAfterInitialization 之中。 是这个原因么？