多线程编程的时候，使用无锁结构会不会比有锁结构更加快？
这是毋庸置疑的，因为线程加锁其实是很吃资源的！我们都知道，多线程模型中，为了避免线程之间的数据互串，影响数据安全，都会在方法或者指定的操作上加锁，最原始的加锁方式就是synchronize，这在以前被称为重度锁，因为加锁是违背了多线程模型的效率的！加锁的原理是什么呢？以a＝1;a＝b＋1为例，编译器编译的时候会在这段代码之前加上一个标志比如说lock，同时在这段代码的后面加上标志unlock，在代码运行期间，一个线程进入这段代码之后先把lock置为加锁位，然后下一个线程过来访问这段代码的时候，发现已经上锁，就只能阻塞等待，等到第一个线程执行完了，把状态改了，然后通知后面的线程去继续执行！当然这是最简化模型的锁，一般锁有读写锁，条件锁，自旋锁等会有不同的唤醒方式和不同的性能消耗！但无论如何，加锁都是在保证数据安全的条件下对多线程性能的污染！那么，怎么避免加锁的性能下降呢？1，从业务上避免大量锁结构的产生！2，使用threadlocal，这能保证每个线程中的数据不会互相污染！3，多读少写的情况，使用读写锁！4，自旋锁会对CPU形成挑战，虽然是线程占用时间很少的锁！5，锁的粒度尽量小:能在方法内的锁，就不要占用整个方法志在用通俗易懂的方式学习高新技术，更多的技术分享，会不定时更新，敬请关注。
当Oracle出现enq: TX - index contention等待事件如何有效解决？
Oracle enq: TX - index contention 索引分裂产生的竞争等待，如果百度会告诉你一堆理论，我建议你可以创建反向索引，可以有效避免索引分裂。示例语法如下：创建test表中 ID 列的反向索引 SQL
