JDBC Type Numeric 对应的Java Type是?
JDBC Type Numeric 对应的 Java Type 是 java.math.BigDecimal
Java
如果要求精确的答案，请避免使用float和double
转自 《effective java》
“” 在java里是啥？
空字符串""到底是什么，有什么特征？ 经过试验，发现： "" != null //true "".length() = 1 "".charAt(0); //报异常，java.lang.StringIndexOutOfBoundsException
为什么网站的在线数统计值为负值？
有一种可能是因为 统计数的加减程序 没有设成synchronized 但还有一种可能： When the server is restarted, if there are active sessions they are persisted by default. Then the server comes back up, and all these sessions are active, without a session created event, so your listener has a counter value of 0, but there are actually >0 active sessions. When these are …
优化AppFuse 1.9.3 SpringMVC IBatis：把类路径下的配置文件挪到src中
某些配置文件应该在src下修改，然后在编译时复制到classes下；而不是直接放在classes下，让人很不习惯。具体有： 1.把classes下的properties.*文件、vm文件、xml文件 都转移到src目录下 2.利用ANT进行编译时应对*.properties.zh_cn文件进行native2ascii
多线程执行多任务 似乎有两种模式
按线程对象的生命周期来分，似乎有两种模式： 1.任务批次一开始就启动一批线程对象，等批次下的所有任务都完成后，线程集体死亡 优点：程序简单明了，对象数固定，性能稳定 缺点：随着任务的减少，空转的线程会越来越多，浪费系统开销 2.任务批次启动后，取一个任务，生成一个线程，这个线程只处理该任务，任务完成后即死亡。当然线程数也不是无限的，到了一定数目后，如果还有新的任务，只能等别的线程死亡、线程总数小于上限后、再孵化出新线程处理新任务。 优点：典型的“池”机制。当任务数少时，线程也少，不存在空转的线程，不浪费CPU 缺点：频繁起线程、杀线程，对CPU也有压力；这种代码编起来也麻烦。
使用HttpClient要注意的问题
1.每次执行一个Method都要release connection，而且要放到finally块里release 2. ONE multi-trhread httpclient = n httpconnections。对同一个Host的默认连接数只有2 3.执行method.getResponseBodyXXX（）方法时，responseBody已经下载到本地。所以，执行这种方法时，程序不会访问网络。
[spring] 使用spring上传时要添加BEAN：“multipartResolver”
<bean id="multipartResolver" class="org.springframework.web.multipart.commons.CommonsMultipartResolver"> </bean> 否则，执行 MultipartHttpServletRequest multiRequest = (MultipartHttpServletRequest) request; 会报 ClassCastException异常
Spring 中上传文件的关键语句
// 转型为MultipartHttpRequest： MultipartHttpServletRequest multipartRequest = (MultipartHttpServletRequest) request; // 获得文件： MultipartFile file = multipartRequest.getFile("filename"); //filename表单参数名 if(MyStringUtil.isEmptyOrNullAfterTrim(file.getOriginalFilename())){ throw new RuntimeException("上传文件不能为空"); } FileCopyUtils.copy(file.getBytes(), objectFile);
AppFuse1.9.3：去掉某个在线用户的权限后，该用户的权限是不是真的马上消失了？
答案是： 不会。去掉用户的权限后，该用户仍然可以执行相关的操作，即使系统管理员 “刷新了缓存” 被去掉权限的用户只有在更新自己的信息、或者退出重新登录以后，才能发现自己失去了指定的权限。 ================================================== 分析： 收集到的事实： 1.去掉用户的某权限（即角色，role）后，该用户查看自己的资料，会发现该角色的确被去掉了，但经过代码跟踪，我发现，该用户对应的Authentication对象中，本来该去掉的authrotiy还在！ 2.用户在登录后，后续的操作不会被 AbstractUserDetailsAuthenticationProvider 拦截。也就是说，用户的Authentication对象不会被更新。相反，这个对象是从SerurityContext中直接取出来的老对象，见 AbstractSecurityInterceptor authenticated = SecurityContextHolder.getContext().getAuthentication() 确认原因： User对象在数据库中被修改后，虽然它在的内存中的对象会被更新(UserSerurityAdvice类中会显式地刷新UserCache)，但其对应的Authentication对象却不会被更新。 ============================================= 解决办法： 1. 配置 filterInvocationInterceptor 的 alwaysReauthenticate属性为true，也就是说用户每进行一次操作，都要去搜集一下它的角色。正如acegi文档所说： It (指 AbstractSecurityInterceptor) also has configurable settings to indicate whether an Authentication object should be re-authenticated on each secure object invocation. By …