2017-09-30 12:52
@LongLee力 play framework 在 render 方法中通过抛出异常来终止当前流程,这个显然是非常错误的做法:
1:异常的创建非常耗时间,而且还耗空间。异常机制的设计初衷是用于不正常的情形,很少有 JVM 实现试图对它们的性能做优化,所以创建、抛出异常开销是很昂贵的
2:将异常用于正常的流程控制,在逻辑上和原则上就是错误的,会引发一些不确定的副作用,这点在 java 最重要的经典书《effective java》 的第 8 章有详细的阐述
2017-09-30 11:22
在 DefaultAccessTokenCache 这个类的 set(String key, String jsonValue) 方法,点击鼠标右键,选择 Open Call Hierarch,能找到所有调用这个 set 方法的地方,通过在这些地方设置断点,看一下到底有没有被调用, 调有物时候 key 值是什么
如果从来没被调用过,或者调时候 key 值另有其人,那么不用我多说了吧?
既然都会用单步调试,为何不再深入调试一下呢? 这种基本问题通过调式分分钟之类解决
据估计, set 方法可能调用过,但调用的时候这个 key 值另有其人,而你再调用 accessTokenCache.get(key) 的时候,根本获取不到,key 值不同,当然就获取到不
还有一个最直接、最快速的调试办法,当程序走到第 51 行时,按 F5 调试进入 accessTokenCache.get(...) 方法内部,查看 AccessTokenCache 内部的这个 map 属性,里面的 key : vlaue 一目了然
2017-09-30 11:10
@WJME 刚看了一下 Captcha 源代码,貌似忘了实现 Serializable 接口了,jfinal 3.3 已添加该实现
2017-09-30 11:07
@WJME 序列化的实现与 Captcha 类没有关系,已实现的序列化方式自然已支持 Captcha 类,否则那就太不通用了