-Flyぁ梦- » 多线程 http://blog.11034.org Sun, 22 Jun 2025 08:59:05 +0000 zh-CN hourly 1 https://wordpress.org/?v=4.2.38 jdk中SimpleDateFormat的实例线程不安全 http://blog.11034.org/2016-03/simpledateformat_thread_not_safe.html http://blog.11034.org/2016-03/simpledateformat_thread_not_safe.html#comments Tue, 01 Mar 2016 03:59:34 +0000 http://blog.11034.org/?p=2779 线上服碰到诡异问题，解析一段无参数固定代码生成的时间字符串获得时间戳，不定概率出现解析异常，堆栈如下。

产生的原因，因为SimpleDateFormat每次new的代价比较高，固定new一个后重复使用。一开始并没有对输入字符串进行日志打印，就以为是输入字符串的错误，就难以定位到产生问题的原因。

[ERROR]2016-03-01 09:03:13,446, [Class]DateTimeUtils, getTimestampFromDateString error : 2013-02-18 09:43:18.0
java.lang.NumberFormatException: For input string: "E.179E11"
    ...
    at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1312)
    at java.text.DateFormat.parse(DateFormat.java:335)
    at com.netease.popo.common.util.DateTimeUtils.getTimestampFromDateString(DateTimeUtils.java)
    ...

明明参数传入的字符串是2013-02-18 09:43:18.0，怎么报异常就变成了E.179E11（有时候报错是空字符串，有时候提示multiple points），就很容易联想到是多线程引起的问题了。

解决的办法：

  1. 每次new SimpleDateFormat(dateTimeFormat).parse(time)，代价比较大
  2. ThreadLocal，给每个线程新建一个SimpleDateFormat对象
  3. 线程安全的第三方库，比如joda-time（org.joda.time）或date4j（www.date4j.net），前者使用更广泛
  • 考虑到使用ThreadLocal需要自己管理且JDK对于日期时间API的弱势，引入一个第三方库对于长远来说也很有必要。
  • 虽然易用性上可能不如date4j更简单，考虑到joda-time使用更广泛资料更多这样也保证了安全和稳定性以及后续的维护代价

综上决定使用joda-time库。但是joda的parse功能并不强大，必须要结合具体的timeFormat才行，这点date4j要强大的多。

下面是根据时间字符串获取时间戳的一个例子，根据业务需求解析了几种常见的日期时间字符串格式。

private static final String dateFormat = "yyyy-MM-dd";
private static final String dateTimeFormat = "yyyy-MM-dd HH:mm:ss";
private static final DateTimeFormatter dateJFormat = DateTimeFormat.forPattern(dateFormat);
private static final DateTimeFormatter dateTimeJFormat = DateTimeFormat.forPattern(dateTimeFormat);
private static final DateTimeFormatter dbJFormat = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss.S");
private static final DateTimeFormatter dateTimeMillJFormat = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss.SSS");
 
public static long getTimestampFromDateString(String time){
	if(StringUtils.isEmpty(time)){
		return 0L;
	}
	int len = time.length();
	try {
		DateTime dateTime = null;
		if(len == 10){
			dateTime = DateTime.parse(time, dateJFormat);
		}
		else if(len == 19){
			dateTime = DateTime.parse(time, dateTimeJFormat);
		}
		else if(len == 21){
			dateTime = DateTime.parse(time, dbJFormat);
		}
		else if(len == 23){
			dateTime = DateTime.parse(time, dateTimeMillJFormat);
		}
		if(dateTime != null){
			return dateTime.getMillis();
		}
		else{
			m_logger.error("getTimestampFromDateString joda miss : " + time);
			return new SimpleDateFormat(dateTimeFormat).parse(time).getTime();
		}
	} catch (Exception e) {
		m_logger.error("getTimestampFromDateString error : " + time, e);
		return 0L;
	}
}

看看 多线程

看看 Java

  • 2016-09-09 -- 64位Linux下Java进程堆外内存迷之64M问题
  • 2016-08-18 -- 读java concurrency in practice
  • 2016-08-05 -- 线程清理
  • 2016-06-21 -- FutureTask简单分析和用法
  • 2016-06-21 -- Semaphore简单分析
    • ]]> http://blog.11034.org/2016-03/simpledateformat_thread_not_safe.html/feed 3 Tomcat的Connector：Coyote http://blog.11034.org/2013-05/coyote.html http://blog.11034.org/2013-05/coyote.html#comments Mon, 20 May 2013 14:01:09 +0000 http://blog.stariy.org/?p=1808 上一篇博文讲了Tomcat的系统架构，今天花了一天时间研究了下coyote的源码，大致对普通IO版本有所了解。被同学提醒后发现，Tomcat6已经支持异步IO了，但默认是普通IO版本，需要在Connector的protocol参数中定义为Http11NioProtocol才开启异步IO模式。

    主要的代码，Socket的服务在org.apache.tomcat.util.net.JIoEndpoint类，解析处理HTTP请求在org.apache.coyote.http11包的Http11Protocol类和Http11Processor类，org.apache.catalina.connector.CoyoteAdapter负责连接Connector模块（coyote）和Container模块。

    线程池默认用的JIoEndpoint类中的子类WorkerStack，若在server.xml配置使用了Executor，则使用org.apache.catalina.core.StandardThreadExecutor（对ThreadPoolExecutor的一层包装）。并发量高的情况下Executor的效率会高一些。

    Coyote普通IO流程

    在Catalina主线程启动过程中：

    StandardService的init()中，在JIoEndpoint.init()中，ServerSocket(port = 8080, backlog = 100)被new出来。

    StandardService的start()中，在JIoEndpoint.start()中，一个新的线程（名叫http-8080-Acceptor-0）被start()，这个由JIoEndpoint.Accept内部类执行run()的线程干的活就是不停地从serverSocket.accept()，然后根据线程池的选择拿一个线程去处理socket。因为处理在新的线程，Acceptor线程继续等待accept()。

    若使用默认的WorkerStack线程池，JioEndpoint.getWorkerThread().assign(socket);使Worker线程获得socket实例后，就可以在新线程中处理socket。

    若使用Executor线程池，则new出一个JioEndpoint.SocketProcessor()交给Executor.execute()，在新线程中处理socket。

    不管哪种线程池方法，新线程中使用一样的代码，调用Http11Protocol$Http11ConnectionHandler.process(socket)，这里使用了一个ConcurrentLinkedQueue用来保存Http11Processor实例，拿一个进行处理。

    Http11Protocol.process()具体解析HTTP请求。解析过程中，将参数塞进request和response，再调用CoyoteAdapter.service(request, response)，这样就进入Container模块去调用Servlet代码。

    结束后，回收Http11Processor实例，回收线程。

    ———————–流程结束分割线—————————

    好像代码也没有太难看不懂，大多数复杂的线程同步操作都由java.util.concurrnt包里的类实现了。

    Worker线程的assign()和await()

    Acceptor线程调用Worker.assign( socket )，将socket对象赋给Worker线程，然后Worker线程中的await()方法通过线程同步，Worker线程被唤醒并拿到了socket就可以在自己线程里顺利执行了。

    这块线程同步的代码蛮有意思的，而且Worker线程也借助这边的wait()和notifyall()实现挂起和唤醒。

    server.xml参数调优

    开启异步IO

    Connector的配置中，将protocol=“HTTP/1.1”改为“org.apache.coyote.http11.Http11NioProtocol”就可以使用nio包的异步IO，效率高不少。

    对java.nio包特别是异步IO这一块了解甚浅，而且Tomcat对这一块的实现略复杂，看懂略有难度，努力！

    同样地方还能改为“org.apache.coyote.http11.Http11AprProtocol”，据说利用底层OS的异步IO，需要APR和Native这其他两个组件的支持才能工作，效率更高，不是太确定。

    开启Executor并在Connector中使用

    Executor的2个配置参数，minSpareThreads和maxThreads，对应到ThreadPoolExecutor(int corePoolSize,  int maximumPoolSize, …)这个构造的前面2个参数。分别表示活跃线程数和最大线程数。

    Connector的参数：

    • maxThreads，对应JIoEndpoint类中的maxThreads变量，默认为200。若有Executor加入则maxThreads被取代。
    • acceptCount，对应JIoEndpoint类中的backlog变量，默认为100，用作ServerSocket的第二个参数。ServerSocket里等待队列的长度。

    看看 coyote , Socket , Tomcat , 多线程 , 异步IO , 线程池

    看看 Java

    • 2016-09-09 -- 64位Linux下Java进程堆外内存迷之64M问题
    • 2016-08-18 -- 读java concurrency in practice
    • 2016-08-05 -- 线程清理
    • 2016-06-21 -- FutureTask简单分析和用法
    • 2016-06-21 -- Semaphore简单分析
      • ]]> http://blog.11034.org/2013-05/coyote.html/feed 1 Tomcat6源码学习 http://blog.11034.org/2013-05/tomcat6.html http://blog.11034.org/2013-05/tomcat6.html#comments Sun, 19 May 2013 10:27:43 +0000 http://blog.stariy.org/?p=1803 在上一篇博文中说到因为电脑风扇坏了2天于是看完了《How tomcat works》译本，不过这本书是针对Tomcat4和5来讲的比较老了，然后再结合Tomcat6.0.26的源代码调试学习了总共一周的时间，算是大致将Tomcat6.0的一部分工作机制（JSP、JMX、安全管理等模块没研究）给搞清楚了。大概是因为平时基于Java的Web程序写的太多，对Tomcat这一块源码研究特别感兴趣，有时候为了想通一个问题兴奋地吃饭睡觉都在一直想，非常有动力并且也有效率，好久没有这种感觉了。

      列几点觉得Tomcat设计上比较有意思的地方。

      Connector模块

      Tomcat主要分为Connector模块和Container模块，前者就是处理Socket和HTTP请求，后者是就是常听到的Servlet容器。

      Connector模块由于功能比较独立，然后Tomcat内部接口的设计允许第三方组件的使用，就使用了Coyote组件，虽然也是apache下的。有空可以再好好来学习下Coyote的源代码，因为这块涉及了多线程和线程同步、资源优化、效率优化等方面，很值得学习。

      Tomcat默认一共占用了3个端口，8080（HTTP/1.1）、8009（AJP/1.3，接受其他服务器转发的请求）和8005（等待SHUTDOWN命令，由Server类在主线程中开启）。其中8080和8009由Connector模块管理，所以默认有2个Connector在运作。

      Container模块

      由Engine、Host、Context、Wrapper四个容器组合而成，分别表示整个引擎、虚拟主机、Web应用、Servlet，通过父子关系连接，然后配套相应的Pipeline和Valve实现过程流。

      Lifecycle接口

      包括启动类（Catalina）、Server、Service、Connector、Container、Executor、Loader、Manager、Realm、Resources、Pipeline都实现了这个接口，通过简单的start()和stop()来递归实现生命周期的管理。

      并且这一模块中还用到了LifecycleListener和LifecycleEvent这套事件驱动模型，虽然觉得Tomcat的事件驱动做的比较一般性，注册在某个Lifecycle的LifecycleListener会收到这个Object的所有事件通知，要靠自己去辨别事件类型并作出相应反应，效率较低且定制性弱。

      ClassLoader的设计

      Tomcat为了使类库的私有性，有commonLoader用来加载lib下的jar包，catalinaLoader和sharedLoader分别用来加载Tomcat类库和应用程序共享类库且都以commonLoader为parent。但是在Tomcat6的配置中，默认没有开启catalinaLoader和sharedLoader也没有相应的server和shared目录，导致这3个loader就是同一个commonLoader。这3个loader是StandardClassLoader的实例。

      然后对于每一个Web应用程序，都有自己的一个WebappClassLoader，其parent为sharedLoader。这样可以防止不同Web应用程序之间加载互相类库。WebappClassLoader和前面提到的StandardClassLoader都继承自java.net.URLClassLoader，直接从指定目录中读取jar包或class文件。WebappClassLoader直接通过管理Servlet类的字节流来实现Servlet的加载然后缓存。

      一般的Servlet只有一个实例，若是实现了STM（SingleThreadModel接口，已Deprecated）的Servlet则会有多个实例缓存着。

      但似乎无论怎么设计，都无法避免Web应用程序中的Servlet可以获取到Tomcat启动库中的Bootstrap类（这个包由JVM自带的AppClassLoader加载），默认情况下还可以获取到Tomcat主类库中的所有类（比如Catalina类，因为都是由commonLoader加载，而它又是WebappClassLoader的parent）。尝试过将Tomcat的lib目录中关于Tomcat的类库放到server目录下并配置server.loader属性值（conf/catalina.properties）启动catalinaLoader，这样可以避免Servlet访问到Tomcat主类库，但是这样勉强的同时也阻止了比如ContainerServlet接口（使Servlet能访问Wrapper容器）的运作。

      这样的一个坏处就是，可以在Web应用程序的Servlet中获取到Catalina类或者Bootstrap类，再启动一次Tomcat。Servlet中，如果在service方法中这么干会被Tomcat的安全机制给发现使得Tomcat整个关闭，若是配置了loadOnStartup后在init方法中这么干则会引发无限循环导致死机…

      不过通过对Tomcat的ClassLoader的学习，对Java的ClassLoader机制有了大大的实践的了解，无论Tomcat是否真正实现了它设计上的初衷，整个设计思想是值得学习的。

      backgroundProcessor()和后台线程

      Engine容器和Context容器都会通过启动一个后台线程间断执行backgroundProcessor方法，比如重新加载Web应用程序的类文件和资源、扫描Session过期等。

      静态资源

      向Tomcat请求静态资源，和请求Servlet没有太大区别，仍然通过Connector和Container这一流程后，交到Tomcat内部的DefaultServlet来处理读取文件内容并写回客户端，下一次请求会返回304 Not Modified。

      所以Tomcat对静态资源的管理比较差速度比较慢，才有apache + tomcat结合的说法吧。

      看看 ClassLoader , HTTP , Servlet , Socket , Tomcat , 事件驱动 , 多线程 , 容器 , 生命周期

      看看 Java

      • 2016-09-09 -- 64位Linux下Java进程堆外内存迷之64M问题
      • 2016-08-18 -- 读java concurrency in practice
      • 2016-08-05 -- 线程清理
      • 2016-06-21 -- FutureTask简单分析和用法
      • 2016-06-21 -- Semaphore简单分析
        • ]]> http://blog.11034.org/2013-05/tomcat6.html/feed 1 HashMap多线程中引发的死循环 http://blog.11034.org/2012-10/hashmap_concurrent_bug.html http://blog.11034.org/2012-10/hashmap_concurrent_bug.html#comments Mon, 01 Oct 2012 08:55:06 +0000 http://blog.stariy.org/?p=1328 串叔发现的问题，觉得很有意思，已有文章作详细描述，把原文翻译地讲一下。原文：http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html。

        Java的HashMap本身就不支持多线程，是线程不安全的，不过代码中有一些机制来阻止多线程中的不安全因素，比如在多线程修改操作中抛出ConcurrentModificationException，但是HashMap忽视了数组扩容时候这一修改操作，从而导致可能在多线程中进行了不安全的操作。

        java.util.HashMap 的 transfer方法：

        1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

        void transfer(Entry[] newTable) {
	Entry[] src = table;
	int newCapacity = newTable.length;
	for (int j = 0; j < src.length; j++) {
		Entry e = src[j];
		if (e != null) {
			src[j] = null;
			do {
				Entry next = e.next;				int i = indexFor(e.hash, newCapacity);
				e.next = newTable[i];
				newTable[i] = e;
				e = next;
			} while (e != null);
		}
	}
}

        假设现在HashMap中的数组的size为2（桶0和桶1），现在有2个Entry A{key=3}和 B{key=7}，于是都位于桶1中形成链表，假设A在B之前，就是array[1]=>A=>B=>null。

        假设有2个线程T1和T2同时进行扩容操作，即会同时调用transfer方法。假设T1先于T2抢到CPU执行transfer方法执行到第9行后切换到T2执行，然后T2顺利执行完毕，然后T1继续执行完毕，看一下这个过程的具体。

        T1先执行到第9行完毕，变量e=A，next=B。

        T2顺利执行完毕，新的数组size为4（桶0-3），A和B还是hash到了同一个桶中，变为T2_newArray[3]=>B=>A=>null，此时A.next=null，B.next=A。

        T1继续执行，第一次循环完毕，T1_newArray[3]=>A=>null，e=B，next=B，e!=null进入下一个循环，此时A.next=null，B.next=A。

        第二次循环完毕，T1_newArray[3]=>B=>A=>null，e=A，next=A，e!=null进入下一个循环，此时A.next=null，B.next=A。

        第三次循环完毕，T1_newArray[3]=>A<=>B，e=null，next=null，e==null跳出循环，此时A.next=B，B.next=A。此时桶3的EntryA和EntryB的next指针互相指向对象，没有一个指向null。

        因为T1后执行完毕，HashMap采用T1_newArray作为新的array（见HashMap的resize方法）。

        T1和T2的扩容操作完毕，并没有引发任何异常和错误，只是埋下了隐患。

        当HashMap继续执行其他get和put操作时，并且得到的hash值为3，即在桶3上进行操作问题就出现了，会进入无限循环，而没有抛出任何异常。

        总结

        不要信任HashMap防止多线程错误的代码，不能对HashMap进行多线程修改的操作，并发读是可以的。

        对HashMap进行线程安全的办法有很多，比如使用java.util.concurrent.ConcurrentHashMap或者使用java.util.Collections.synchronizedMap(Map<K,V> m)方法包装HashMap，或者在自己调用HashMap的方法中使用同步机制。

        看看 多线程

        看看 Java