thread-local

问题 I am currently programming a python-based datagram-Server using threads and all of that. I encountered the following problem: I am using multiple Allocation Threads to allocate incoming packages to the different processing threads. Inside the Processing Threads, I am using threading.local() to keep track of thread-local variables. I am currently testing how my server reacts during high load (2000 Packets in ~2 seconds), and have come upon a strange behaviour of the local()-Object. It seems

问题 Whenever I stop or redeploy the webapp, I see lot of errors similar to, msg=The web application [] created a ThreadLocal with key of type [] (value []) and a value of type [] (value []) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid probable memory leak I'm not creating any ThreadLocals in my app but referencing many libraries which may be creating these ThreadLocals. We are currently using Tomcat 7. I've already gone

问题 /* We are using Aspect to do AOP on some existing application and we also used threadlocal to store GUId. we are using @Around annotation. At the start of the transaction we are setting the GUID in transaction with initialValue() method. Issue is as we know when we are using threadlocal we should also take care about removing the data from threadlocal otherwise it may result i outofmemory execption. if i am removing it at the last of the aspect it is corrupting the code and changing the UUID

问题 I'm using a custom interceptor which creates a new db connection, and sets this connection onto the current action before executing the action. After that, the interceptor closes the connection. I'm looking for a convenient way to share this db connection with other classes / static methods (such as Models) that are used by the action. E.g so I can call static method like User.get( id ) or User.getEmail( id ) without having to pass the db connection to each method separately. I could set the

问题 I have a logging system, which basically uses a thread-local buffer to log. This helps in reducing locking. A bunch of message can be written into the thread-local buffer and flushed in one shot. And also since it is thread-local, we can avoid allocating buffer per log message. Anyway the issue is during the process exit. We are seeing crash while accessing the thread-local buffer. The thread-local object I have is something like std::vector<Buffer> . [ vector because there are multiple

问题 I have a number of Java date patterns and want to reuse them multiple times in SimpleDateFormat objects across different threads, via static references, for speed. The code would look something like this (inside a class called, say, FormatClass ): private static String[] PATTERNS = new String[] {...}; public ThreadLocal<SimpleDateFormat[]> LOCAL_FORMATS = new ThreadLocal<SimpleDateFormat[]> { @Override protected SimpleDateFormat[] initialValue() { List<SimpleDateFormat> formatList = new

问题 Is it a good idea to use ThreadLocal as a context for data in web application? 回答1: That's what it was made for. But take care to remove the ThreadLocal on the end of the context, else you might run in memory leaks, or at least hold unused data for too long. ThreadLocals are also very fast, you can think of it as a HashMap<Thread,Object> , which is always queried with Thread.getCurrentThread() . 回答2: That depends on the scope of the data. The ThreadLocal will be specific to the request thread

问题 Using a pattern very similar to that described in a recent question, for a multithreaded application, I am getting weird date values (e.g., years like 2025 or 2035, when clearly no such value exists in the source data). It seems that a concurrency issue is occuring. The source code looks something like // Various Java DateFormat patterns, e.g. "yyyy-MM-dd". private static final String[] DATE_PATTERNS = new String[] {...}; private static SimpleDateFormat[] getFormats(final String[] patterns) {

问题 The well acclaimed book JCIP says this about ThreadLocal usage : It is easy to abuse ThreadLocal by treating its thread confinement property as a license to use global variables or as a means of creating "hidden" method arguments. Thread-local variables can detract from reusability and introduce hidden couplings among classes, and should therefore be used with care. What does it mean by saying that Thread-local variables can reduce reusability and introduce hidden couplings among classes? 回答1

问题 As shown in this answer, clang from Xcode on Mac OSX does not support thread_local storage even with C++11 flags set. Even on the latest version, Apple LLVM version 7.0.0 (clang-700.1.76), Target: x86_64-apple-darwin15.0.0, Thread model: posix, does not support thread_local : ../../src/dir/sysArch.h:1505:3: error: thread-local storage is not supported for the current target thread_local ^ 回答1: The version of clang supplied with Xcode 8 (and later) supports the thread_local keyword; see the