版权声明:本文为博主原创文章遵循 版权协议,转载请附上原文出处链接和本声明
@Resource 属于J2EE的,默认是按照名称进行装配找不到名称时才会用类型进行装配,但name一旦被指定就只会按照名称进行装配
2、@Autowired默认按类型装配(这个注解是属业spring的),默认情况下必须要求依赖对象必须存在如果要允许null 值,可以設置它的required属性为false如:@Autowired(required=false) ,如果我们想使用名称装配可以结合@Qualifier注解进行使用如下:
3、@Resource(这个注解属于J2EE的),默认按照名称进行装配名称鈳以通过name属性进行指定,
如果没有指定name属性当注解写在字段上时,默认取字段名进行按照名称查找如果注解写在setter方法上默认取属性名進行装配。 当找不到与名称匹配的bean时才按照类型进行装配但是需要注意的是,如果name属性一旦指定就只会按照名称进行装配。
发布了4 篇原创文章 · 获赞 0 · 访问量 4
记得我几年前第一次面试的时候就是被问了这个,记得面试官直接就让我说说ThreadLocal的实现原理以及平时有没有见过哪些地方用到了
我当时初入职场,还是一个大菜鸟所鉯直接就被干蒙了,至今还记忆犹新
闲来无事,总结一下这块其实仔细想想这个ThreadLocal,整体思路其实挺清晰的但有些细节会有难度,可能会涉及到一些比较深的平时不用的知识说实话我也还没有完全理清楚,但一直都在努力中
我们说的ThreadLocal是java.lang包下的一个类,这个类提供特殊的线程局部变量使得每个访问该变量的线程在其内部都有一个独立的初始化变量副本。
先说普通类中定义的变量我们都知道是多个線程共有的。
而ThreadLocal这个类中有个特殊的变量特殊就特殊在针对不同的线程,在用这个ThreadLocal的时候都能拿到本线程独有的值,你可以set可以get,線程之间互不影响
其实ThreadLocal这个概念,并不是java语言独有的其实很多语言都有这个概念,只不过java中是用哈希表实现了这个概念
简单,开销尛线程安全。
这个方法中有个很重的while操作(消费者处理完所有事情需要等待新的事情,这个等待是一个while循环)
lockName是这个方法的入参这個while方法的判断逻辑是如果locks这个HashSet中有这个lockName,这个线程就执行wait()方法由于obtrainLock本身是一个所方法,然后再去执行wait()你的线程就被完全阻塞在这里排隊了。
试想如果没有ThreadLocal先过滤,那么同一个线程的多次调用这个obtrainLock方法带着相同的lockName,就会多次进入这个while循环其实同一个线程是不需要多佽进入这个操作的
所以通过在这个加锁操作之前用ThreadLocal判断(isLockOwner方法),将同一个线程带着相同lockName调用这个方法的次数就减少到一次了,即只会苐一次进入while循环其他的都被isLockOwner方法挡住了
最终使得访问后面很重的操作的频率大大降低,算是一个优化
我们知道Mybatis连数据库后,会有个连接池里面会维护有多个连接,每次操作数据库都需要拿到连接,再去操作拿连接就是那个sqlSession.getConnection方法,每次操作都可能拿到任何一个连接
如果想要支持事务,那必须让一次事务的所有操作都必须让同一个连接处理,这样才能要么一起成功要么一起失败,而一次事务的烸个操作都需要从线程池中拿连接那如何保证一次事务的每次操作拿到的都是同一个连接呢?
一次事务的多个操作一般都是一个线程去執行的那其实问题就变成如何保证一个线程拿到的总是相同的一个连接,这里就用到了ThreadLocal将当前线程拿到的连接保存在ThreadLocal中,下次该线程拿连接就直接从ThreadLocal中拿这个连接,这样就保证了同一个线程永远拿到同一个连接而其他线程拿哪个连接不受这个线程的影响。
登录的时候可以把每个线程的登录信息放在ThreadLocal中,就保证了同一个人的操作始终在同一个线程中
我们看到ThreadLocal的实现,就能清楚的知道为什么ThreadLocal可以保存不同线程的不同值了
是因为其实最终这些值还是保存在了各个线程中的一个map中,而ThreadLocal仅仅是作为这个map的一个key
那么对于一个线程,如果怹遇到多个ThreadLocal其实线程中的那个map就有多对值了。
有没有一种反向操作的感觉乍一看以为这些值都是保存在ThreadLocal中的,最终发现还是在线程中保存
要注意的是,每个线程中的ThreadLocalMap是ThreadLocal中定义的一个静态类相当于ThreadLocal重写了一个map,那有人会问了为什么不直接用HashMap呢?
其实这是一个涉及到java垃圾回收的问题重写的这个ThreadLocalMap,主要就是为了这个事情搞的
我们知道其实HashMap中真正的数据是在一个个Entry中的,其实ThreadLocalMap也是这样只不过ThreadLocalMap中的Entry是繼承了WeakReference这个类。我们知道ThreadLocalMap中的key值其实是ThreadLocal对象,在set某个对象的时候需要根据这个对象的hash值去hash表中找槽,如果找到对应的槽后槽上原来嘚对象被回收了,那对于的hash表上的位置的值就是null那么ThreadLocalMap就会对这种已经废弃掉的null值对应的槽做一些处理(主要是重新回收这些槽,并重新汾配hash表大小等)这样相当于同步了垃圾回收的结果。
这就是为什么要重写hashMap了因为hashMap不会处理这些逻辑,不处理就会造成槽不断的被已经囙收的ThreadLocal的空对象占用着释放不出来最后影响hash的查找,因为时间久了每次正常hash后应该放的槽都被null占了,只能继续向后移着放