synchronized

Java面试汇总

喜你入骨 提交于 2019-12-02 05:32:30
首先,感谢这篇文章的作者分享! 本文分为十九个模块,分别是: Java 基础、容器、多线程、反射、对象拷贝、Java Web 、异常、网络、设计模式、Spring/Spring MVC、Spring Boot/Spring Cloud、Hibernate、MyBatis、RabbitMQ、Kafka、Zookeeper、MySQL、Redis、JVM ,如下图所示: 共包含 208 道面试题,本文的宗旨是为读者朋友们整理一份详实而又权威的面试清单,下面一起进入主题吧。 Java 基础 1. JDK 和 JRE 有什么区别? JDK:Java Development Kit 的简称,Java 开发工具包,提供了 Java 的开发环境和运行环境。 JRE:Java Runtime Environment 的简称,Java 运行环境,为 Java 的运行提供了所需环境。 具体来说 JDK 其实包含了 JRE,同时还包含了编译 Java 源码的编译器 Javac,还包含了很多 Java 程序调试和分析的工具。简单来说:如果你需要运行 Java 程序,只需安装 JRE 就可以了,如果你需要编写 Java 程序,需要安装 JDK。 2. == 和 equals 的区别是什么? == 解读 对于基本类型和引用类型 == 的作用效果是不同的,如下所示: 基本类型:比较的是值是否相同; 引用类型

Java 字节流操作1

断了今生、忘了曾经 提交于 2019-12-02 05:26:53
 转自: https://www.cnblogs.com/yangming1996/p/6549800.html   在java中我们使用输入流来向一个字节序列对象中写入,使用输出流来向输出其内容。C语言中只使用一个File包处理一切文件操作,而在java中却有着60多种流类型,构成了整个流家族。看似庞大的体系结构,其实只要使用适合的方法将其分门别类,就显得清晰明了了。而我准备将其按照处理文件类型的不同,分为字节流类型和字符流类型。共两篇文章,本篇从字节流开始。主要包含以下内容: InputStream/OutPutStream - - -字节流基类 FileInputStream/FileOutputStream - - - - -处理文件类型 ByteArrayInputStream/ByteArrayOutputStream - - - -字节数组类型 DataInputStream/DataOutputStream - - - -装饰类 BufferedInputStream/BufferedOutputStream - - - -缓冲流 一、基类流 其实始终有人搞不清楚到底InputStream是读还是OutputStream是读。其实很简单就可以记住,你把你自己想象为是一个程序,InputStream对你来说是输入,也就是你要从某个地方读到自己这来

Synchronized的底层实现原理

非 Y 不嫁゛ 提交于 2019-12-02 05:08:44
Synchronized的底层实现原理 如果我们要想了解synchronized底层实现原理,那么不妨先来了解了解对象在堆中的存储结构 java对象在堆中的存储结构分为三个部分,分别为对象头、实例变量和填充字节。 对象头里面主要包含MarkWord和Klass Point类型指针,MarkWord里面存储的是对象自身的运行时数据(包含了Hashcode、GC分带年龄、锁状态标记、线程持有的锁等等),而Klass Point则指向的是类元数据的指针,JVM就是通过此指针来确定这个对象是哪个类的实例。 实例变量里面存储的是对象的属性信息,包括父类的属性信息,按照4个字节对齐 填充字节则是因为java虚拟机要求对象字节数必须是8的整数倍,填充字节就是用于凑齐这个倍数用的。 在JVM中,synchronized的对象锁,其指针指向的是一个monitor对象(由C++实现的ObjectMonitor对象)的起始地址。它的大致数据结构如下: ObjectMonitor ( ) { _count = 0 ; //用来记录该对象被线程获取锁的次数 _waiters = 0 ; _recursions = 0 ; //锁的重入次数 _owner = NULL ; //指向持有ObjectMonitor对象的线程 _WaitSet = NULL ; //处于wait状态的线程,会被加入到

Java中Synchronized的优化原理

假装没事ソ 提交于 2019-12-02 04:58:30
我们知道,从 JDK1.6 开始,Java 对 Synchronized 同步锁做了充分的优化,甚至在某些场景下,它的性能已经超越了 Lock 同步锁。那么就让我们来看看,它究竟是如何优化的。 原本的问题 Synchronized 是基于底层操作系统的 Mutex Lock 实现的,每次获取锁和释放锁的操作都会带来 用户态 和 内核态 的切换,从而增加系统性能开销。 因此,在锁竞争激烈的情况下, Synchronized 同步锁在性能上就表现得非常糟糕,它也常被大家称为 重量级锁 。 到了 JDK1.5 版本,并发包中新增了 Lock 接口来实现锁功能,它提供了与 Synchronized 关键字类似的同步功能,只是在使用时需要显示获取锁和释放锁。 在单个线程重复申请锁的情况下,JDK1.5 版本的 Lock 性能要比 Synchronized 锁的性能好很多,也就是当时的 Synchronized 并不具备 可重入锁 的功能。 那么当时的 Synchronized 是怎么实现的?又为什么不具备可重入的功能呢? Synchronized原理 JVM 中的同步是基于进入和退出管程(Monitor)对象实现的。每个对象实例都会有一个 Monitor,Monitor 可以和对象一起创建、销毁。 当多个线程同时访问一段同步代码时,多个线程会先被存放在 EntryList集合 (也可称为

In Java, how do I test if an object's monitor is locked? [duplicate]

独自空忆成欢 提交于 2019-12-02 04:58:17
This question already has an answer here: How do determine if an object is locked (synchronized) so not to block in Java? 7 answers Java: How to check if a lock can be acquired? [duplicate] 3 answers In Java, how do I test if an object's monitor is locked? In other words, given a object obj, does any thread own obj's monitor? I do not care which thread owns the monitor. All I need to test is if ANY thread owns a given object's monitor. Since a thread other than the current thread could own the monitor, Thread.holdsLock( obj ) is not enough as it only checks the current thread. I am trying to

Why is Java synchronized not working as expected?

浪子不回头ぞ 提交于 2019-12-02 04:03:37
I'm trying to figure out how synchronized methods work. From my understanding I created two threads T1 and T2 that will call the same method addNew , since the method is synchronized shouldn't it execute all the iterations of the for loop for one thread and then the other? The output keeps varying, sometimes it prints it right, other times it prints values from T1 mixed with T2 values. The code is very simple, can someone point out what am I doing wrong? Thank you. public class Main { public static void main(String[] args) { Thread t1 = new Thread(new A()); Thread t2 = new Thread(new A()); t1

Synchronized section in async map

荒凉一梦 提交于 2019-12-02 03:50:26
I have a big IO function that will continuesly load data from a folder, perform pure calculations on the data, and write it back. I am running this function over multiple folders in parallel using mapConcurrently_ iofun folderList from http://hackage.haskell.org/package/async-2.1.1.1/docs/Control-Concurrent-Async.html#v%3amapConcurrently This works perfecty... but a little bit too well. Now even the character output of the putStrLn calls are async, which leads to an unreadable console log. Is there a way to make IO Actions synchronized or even better a synchronized version of putStrLn? The way

第九周课程总结及实验报告

爱⌒轻易说出口 提交于 2019-12-02 03:39:08
实验报告 完成火车站售票程序的模拟。 要求: (1)总票数1000张; (2)10个窗口同时开始卖票; (3)卖票过程延时1秒钟; (4)不能出现一票多卖或卖出负数号票的情况。 1)实验代码 package text8; public class MyThread implements Runnable{ private int tickets=1000; public int getTickets() { return tickets; } public void setTickets(int tickets) { this.tickets = tickets; } public void run() { while(true) { synchronized(this){ try { if(tickets>0) { System.out.println(Thread.currentThread().getName()+":是第 "+tickets+" 张票 "); tickets--; } Thread.sleep(1000); }catch(Exception e) { System.out.println(e.getMessage()); } } if(tickets<=0){ break; } } } } package text8; public class Text8

Should I volatile the field with synchronized methods?

大憨熊 提交于 2019-12-02 03:36:00
问题 With following class, // This class should be thread-safe!!! class BankAccount { private long balance; // Should it be volatile? synchronized void deposit(long amount) { // ... balance += amount; } synchronized void withdraw(long amount) { // ... balance -= amount; } } Should I add volatile to balance field? 回答1: No, compared with synchronized keyword, volatile is lightweight. volatile can gurantee the reader thread always get fresh balance value, but it can not make balance += amount; atomic

CAS原子性操作

六眼飞鱼酱① 提交于 2019-12-02 03:26:52
重要网址 https://blog.csdn.net/wufaliang003/article/details/78797203 ABA问题详细介绍 一、什么是CAS操作 cas全称是compare and swap 比较交换 传入三个参数,旧的值、期待的值、想替换的值。会获得变量的之前的值,与期待的值相比,如果相同替换值给变量,如果不同返回false。 cas是unsafe类下的native方法,使用c++进行实现,主要是直接操作cpu指令进行原子性操作。 cas使用于低并发的场景。 二、CAS和synchronized适用场景 1、对于资源竞争较少的情况,使用synchronized同步锁进行线程阻塞和唤醒切换以及用户态内核态间的切换操作额外浪费消耗cpu资源; 而CAS基于硬件实现,不需要进入内核,不需要切换线程,操作自旋几率较少,因此可以获得更高的性能。 2、对于资源竞争严重的情况,CAS自旋的概率会比较大,从而浪费更多的CPU资源,效率低于synchronized。 使用CAS在线程冲突严重时,会大幅降低程序性能;CAS只适合于线程冲突较少的情况使用。而synchronized在jdk1.6之后,已经改进优化。synchronized的底层实现主要依靠Lock-Free的队列,基本思路是自旋后阻塞,竞争切换后继续竞争锁,稍微牺牲了公平性,但获得了高吞吐量