㈠ java中的内锁机制是什么
多线程同步的实现最终依赖锁机制。我们可以想象某一共享资源是一间屋子，每个人都是一个线程。当A希望进入房间时，他必须获得门锁，一旦A获得门锁，他进去后就立刻将门锁上，于是B,C,D...就不得不在门外等待，直到A释放锁出来后，B,C,D...中的某一人抢到了该锁（具体抢法依赖于JVM的实现，可以先到先得，也可以随机挑选），然后进屋又将门锁上。这样，任一时刻最多有一人在屋内（使用共享资源）。 Java语言规范内置了对多线程的支持。对于Java程序来说，每一个对象实例都有一把“锁”，一旦某个线程获得了该锁，别的线程如果希望获得该锁，只能等待这个线程释放锁之后。获得锁的方法只有一个，就是synchronized关键字。
㈡ java多用户同时修改一条数据时乐观锁怎么用的
你说的这个version是mysql底层的锁机制提供的，并不是java提供的。
使用数据版本（Version）记录机制实现，这是mysql乐观锁最常用的一种实现方式。所谓的数据版本就是给数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，版本号重新读取再做更新。
㈢ 关于JAVA里的加锁synchronized
1.凡使用synchronized标记的方法，比如 public synchronized void func1() { .... }，则同时只有一个线程能够运行这个方法。比如，线程1正在运行func1，则其他线程需要运行func1的话，会卡住，等线程1运行func1结束后，其他线程中，才会有一个幸运儿成功争取到运行func1的资格，然后这个幸运儿线程开始运行func1。没有争取到运行资格的其他线程，会继续等待。
2.你的例子中，被锁定的是 方法 m1，而不是属性b。所以，m1的synchronized加锁操作，与b没有半点毛钱关系。
3.要实现你的锁b想法，其实很简单。去买一件贞操宝甲来就行了。开玩笑，哈哈。要锁b，把main方法里的tt.m2()修改为tt.m1()。
4.以后别用“b”作为变量，总觉得怪怪了。也许你现在还没长大，很单纯。但大人的世界里，“b”是一种不文雅但又对人类的未来有重要作用的东西。建议用cb来代替b。
㈣ java中的锁有哪几种
lock比synchronized比较如下：
1) 支持公平锁，某些场景下需要获得锁的时间与申请锁的时间相一致，但是synchronized做不到
2) 支持中断处理，就是说那些持有锁的线程一直不释放，正在等待的线程可以放弃等待。如果不支持中断处理，那么线程可能一直无限制的等待下去，就算那些正在占用资源的线程死锁了，正在等待的那些资源还是会继续等待，但是ReentrantLock可以选择放弃等待
3) condition和lock配合使用，以获得最大的性能
JAVA中锁使用的几点建议：
1.如果没有特殊的需求，建议使用synchronized，因为操作简单，便捷，不需要额外进行锁的释放。鉴于JDK1.8中的ConcurrentHashMap也使用了CAS+synchronized的方式替换了老版本中使用分段锁（ReentrantLock）的方式，可以得知，JVM中对synchronized的性能做了比较好的优化。
2.如果代码中有特殊的需求，建议使用Lock。例如并发量比较高，且有些操作比较耗时，则可以使用支持中断的所获取方式；如果对于锁的获取，讲究先来后到的顺序则可以使用公平锁；另外对于多个变量的锁保护可以通过lock中提供的condition对象来和lock配合使用，获取最大的性能。