java tips

Posted 2021-01-02 dayspring

getWriter() has already been called for this response

reason: getWriter和getOutputStream(chain.doFilter(request, response);) 二者只能选其一，调用了其中一个就不能调用另一个了

 

3 ways to cut out a string

 

• split(using RegEx, not KMP string matching arithmetic, splite one time)
• StringTokenizer(not recommended by jdk, just a legacy class, be retained for compatibility reason, split in turn)
• substring

java中获取比毫秒更为精确的时间  

System.currentTimeMillis() 的文档，原来这个方法调用了个native方法，获取的时间精度会依赖于操作系统的实现机制

在Java中可以通过System.currentTimeMillis()或者System.nanoTime() (JDK>=5.0) 方法获得当前的时间的精确值。但是通过阅读Javadoc，我们发现这两个方法并不一定保证得到你所期望的精度。先来看System.currentTimeMillis()：

Returns the current time in milliseconds. Note that while the unit of time of the return value is a millisecond, the granularity of the value depends on the underlying operating system and may be larger. For example, many operating systems measure time in units of tens of milliseconds.

如何在windows上实现精确的毫秒计时呢。答案就是用“System.nanoTime()/1000000L”代替“System.currentTimeInMills()”

http://blog.csdn.net/paul_lh/article/details/6419982

秒的换算：ms(毫秒),μs(微秒),ns(纳秒),ps(皮秒)

 

SimpleDateFormat && Calendar is not thread safe

关于获取时间的一些类，如java.util.Date, java.util.Calendar都不是线程安全的

还有就是对时间格式化时,DateFormat和SimpleDateFormat也不是线程安全的~作为一个专业程序员，我们当然知道，相比于共享一个变量的开销要比每次创建小。之所以我们必须这么做，是因为SimpleDateFormat不是线程安全的。但从SimpleDateFormat提供给我们的接口上来看，实在让人看不出它与线程安全有和相干。那接下来，我们就要打开JDK的源码，看一下其中的代码之丑。

在format方法里，有这样一段代码： calendar.setTime(date);

其中，calendar是DateFormat的protected字段。这条语句改变了calendar，稍后，calendar还会用到（在subFormat方法里），而这就是引发问题的根源。

稍微花点时间分析一下format的实现，我们便不难发现，用到calendar，唯一的好处，就是在调用subFormat时，少了一个参数，却带来了这许多的问题。其实，只要在这里用一个局部变量，一路传递下去，所有问题都将迎刃而解。

这个问题背后隐藏着一个更为重要的问题：无状态。

无状态方法的好处之一，就是它在各种环境下，都可以安全的调用。衡量一个方法是否是有状态的，就看它是否改动了其它的东西，比如全局变量，比如实例的字段。format方法在运行过程中改动了SimpleDateFormat的calendar字段，所以，它是有状态的。

写程序，我们要尽量编写无状态方法。