JAVA随笔

客官°小女子只卖身不卖艺 2022-12-03 13:22 119阅读 0赞

# 1、内存泄漏的一点思考（JAVA） #

参考：[http://blog.csdn.net/anxpp/article/details/51325838][http_blog.csdn.net_anxpp_article_details_51325838]

**一句话：命长的拉着命短的不放手(引用)，导致命短的不能死去(gc)。**

我们举一个简单的例子：

public class Simple { 
        Object object;
        public void method1(){ 
            object = new Object();
            //...其他代码
        }
    }

这里的object实例，其实我们期望它只作用于method1()方法中，且其他地方不会再用到它，但是，当method1()方法执行完成后，object对象所分配的内存不会马上被认为是可以被释放的对象，只有在Simple类创建的对象被释放后才会被释放，严格的说，这就是一种内存泄露。

解决方法就是将object作为method1()方法中的局部变量。当然，如果一定要这么写，可以改为这样：

public class Simple { 
        Object object;
        public void method1(){ 
            object = new Object();
            //...其他代码
            object = null;
        }
    }

网上很多博客都会谈到**TreadLocal**存在内存泄漏问题，有丰富理论和代码论证，比如如下博客：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70_pic_center]

该博客的分析是没有问题的，的确线程池中的线程持有Entry数组中的Entry对Value持有强引用，因此即使ThreadLocal对象因为作用域不存在而被gc,但是int\[\]数组不会被gc。

但是谁会在线程中不断的new ThreadLocal对象呢？

ThreadLocal对象一般用于存储线程上下文，一般都会定义成static的。

有人认为**TreadLocal**对象只执行**set**而从不**remove**就会造成内存泄漏，比如：

[ThreadLocal出现OOM内存溢出的场景和原理分析][ThreadLocal_OOM]

我认为这篇博客是错误的，因为这不存在命长的对象持有短名鬼，其中ThreadLocal对象是static的，其生命周期和线程都和程序生命周期一致，每次执行set方法，key都是那个key，value引用才是不断变化的，但旧的对象会因为没有value引用而可以被GC呀！上面这篇文章的现象，仅仅是内存溢出，而不是内存泄漏！

# 2、synchronized优化 #

在 Java 5 之前，synchronized依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作是一个无差别的重量级操作。

现代的（Oracle）JDK 中，JVM 对此进行了大刀阔斧地改进，提供了三种不同的 Monitor 实现，也就是常说的三种不同的锁：偏斜锁（Biased Locking）、轻量级锁和重量级锁，大大改进了其性能。

当没有竞争出现时，默认会使用偏斜锁。JVM 会利用 CAS 操作（compare and swap），在对象中记录线程 ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁。这样做的假设是基于在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。

比如web应用的转账操作，账户A给账户B转账，为了防止同时存在涉及账户A和B的转账操作，必须对账户A和账户B加锁，但是试问又有多大可能存在上述并发呢？但是1.5以前也只能使用synchronized来同步，所以每次都切换到内核态都是无用功！

锁的4中状态：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态（级别从低到高）

（1）偏向锁：

为什么要引入偏向锁？

因为经过HotSpot的作者大量的研究发现，大多数时候是不存在锁竞争的，常常是一个线程多次获得同一个锁，因此如果每次都要竞争锁会增大很多没有必要付出的代价，为了降低获取锁的代价，才引入的偏向锁。

偏向锁的升级

当线程1访问代码块并获取锁对象时，会在java对象头和栈帧中记录偏向的锁的threadID，因为偏向锁不会主动释放锁，因此以后线程1再次获取锁的时候，需要比较当前线程的threadID和Java对象头中的threadID是否一致，如果一致（还是线程1获取锁对象），则无需使用CAS来加锁、解锁；如果不一致（其他线程，如线程2要竞争锁对象，而偏向锁不会主动释放因此还是存储的线程1的threadID），那么需要查看Java对象头中记录的线程1是否存活，如果没有存活，那么锁对象被重置为无锁状态，其它线程（线程2）可以竞争将其设置为偏向锁；如果存活，那么立刻查找该线程（线程1）的栈帧信息，如果还是需要继续持有这个锁对象，那么暂停当前线程1，撤销偏向锁，升级为轻量级锁，如果线程1 不再使用该锁对象，那么将锁对象状态设为无锁状态，重新偏向新的线程。

（2）轻量级锁

为什么要引入轻量级锁？

轻量级锁考虑的是竞争锁对象的线程不多，而且线程持有锁的时间也不长的情景。因为阻塞线程需要CPU从用户态转到内核态，代价较大，如果刚刚阻塞不久这个锁就被释放了，那这个代价就有点得不偿失了，因此这个时候就干脆不阻塞这个线程，让它自旋这等待锁释放。

轻量级锁什么时候升级为重量级锁？

线程2的CAS失败，那么线程2就尝试使用自旋锁来等待线程1释放锁。

但是如果自旋的时间太长也不行，因为自旋是要消耗CPU的，因此自旋的次数是有限制的，如果自旋次数到了线程1还没有释放锁，或者线程1还在执行，线程2还在自旋等待，这时又有一个线程3过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。

# 3.mybatis的collection+select性能太差 #

会串行的执行子查询，导致执行SQL非常多  
采用collection+resultmap+join一次性查询性能可能会好很多。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70]

# 4. MySQL #

group by a,b,c order by null 通过order by null 避免group by 的排序，提高性能

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70 2]

[http_blog.csdn.net_anxpp_article_details_51325838]: http://blog.csdn.net/anxpp/article/details/51325838
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/dcb25abc929d483eb2aeb63003a9e1c7.png
[ThreadLocal_OOM]: https://blog.csdn.net/GoGleTech/article/details/78318712?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-6.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-6.channel_param
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70]: /images/20221123/93e34c63ac26463283df53cb1568e20d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70 1]: /images/20221123/8a038b627f2c45b1b69f15c5fe75fece.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3pob3V3ZW5qdW4wODIw_size_16_color_FFFFFF_t_70 2]: /images/20221123/92174c6fd10c4bfd995cf89c1af16458.png