Nginx+JVM
一、Nginx:
1、Nginx下载:
Nginx安装时必须确保操作系统安装有GCC(GNU Compiler Collection)编辑的语言
安装命令为:
yum -y install gcc gcc-c++ autoconf automake
模块依赖性:
Nginx的一些模块需要其它第三方库的支持,例如gzip模块需要zlib库,rewrite模块需要pcre库,ssl功能需要openssl库等
安装命令为:
yum -y install zlib zlib-devel openssl openssl-devel pcre pcre-devel
GCC:GNU社区推出的功能强大、性能优越的用于编程开发的自由编译器
下载:
通过http://www.nginx.net/
下载即可
2、Nginx安装:
在Linux,通过编译源码的方式来安装,最简单的安装命令如下:
tar -zxvf nginx-0.x.xx.tar.gzcd nginx-0.x.xx./configuremakesudo make install
通过以上命令,Nginx将默认安装到/usr/local/nginx
目录下,可以通过./configure --help
命令查看Nginx可选择的编译选项
Nginx的configure脚本支持以下选项:
--prefix=<path> ------ Nginx安装路径,如果没有指定,默认为/usr/local/nginx--sbin-path=<path> ------ Nginx可执行文件安装路径,只能安装时指定,如果没有指定,默认为<prefix>/conf/nginx.conf--pid-path=<path> ------ 在nginx.conf中没有指定pid指令的情况下,默认的Nginx.pid的路径如果没有指定,默认为<prefix>/logs/nginx.pid--lock-path=<path> ------ nginx.lock文件的路径--error-log0path=<path> ------ 在nginx.config中没有指定error_log指令的情况下,默认的错误日志的路径,如果没有指定,默认为 <prefix>/logs/error.log--http-log-path=<path> ------ 在nginx.config中没有指定access_log指令的情况下,默认的访问日志的路径,如果没有指定,默认为<prefix>/logs/access.log......
3、Nginx的基本配置与优化:
Nginx的配置文件默认在Nginx程序安装目录的conf二级目录下,主配置文件为nginx.conf
Nginx作为Web Server的完整配置如下:
# 试用的用户和组userwww www;# 指定工作衍生进程数(一般等于CPU的总核数或总核数的两倍,例如两个四核CPU,则总核数为8)worker_processes8;# 指定错误日志存放的路径,错误日志记录级别可选项为:【debug | info | notice | warn | error | crit】error_log/datal/logs/nginx_error.log crit;# 指定pid存放的路径pid/usr/local/webserver/nginx/nginx.pid;# 指定文件描述符数量worker_rlimit_nofile51200;events{# 使用的网络I/O模型,Linux系统推荐采用epoll模型,FreeBSD系统推荐采用kqueue模型use epoll;# 允许的连接数worker_connections51200;}http{includemime.types;default_typeapplication/octet-stream;# 设置使用的字符集,如果一个网站有很多字符集,请不随便设置,应让程序员在HTML代码中通过Meta标签设置#charsetgb2312;server_name_hash_bucket_size128;client_header_buffer_size32k;large_client_header_buffers432k;# 设置客户端能够上传的文件大小client_max_body_size8m;sendfileon;tcp_nopushon;keepalive_timeout60;tcp_nodelayon;fastcgi_connect_timeout300;fastcgi_send_timeout300;fastcgi_read_time300;fastcgi_buffer_size64k;fastcgi_buffers464k;fastcgi_busy_buffers_size128k;fastcgi_temp_file_write_size128k;# 开启gzip压缩gzipon;gzip_min_length1k;gzip_buffers416l;gzip_http_version1.1;gzip_comp_level2;gzip_typestext/plainapplication/x-javascripttext/cssapplication/xml;gzip_varyon;#limit_zonecrawler$binary_remote_addr10;server{listen80;server_namewww.yourdomain.comyourdomain.com;index index.htmlindex.htmindex.php;root/data0/htdocs;#limit_conncrawler20;# 浏览器本地缓存设置# 对常见格式的图片、Flash文件在浏览器本地缓存30天location ~ .*\.(if|jpg|jpeg|png|bmp|swf)${expires30d;}# 对js、css文件在浏览器本地缓存1小时location ~ .\.(js|css)?{expires1h;}log_formataccess'$remote_addr - $remote_user "[$time_local]" ''$status $boby_bytes_sent "$http_referer" ''"$http_user_agent" $http_x_forwarded_for';access_log/datal/logs/access.logaccess;}}
Nginx的虚拟主机配置:
http{# 第一个虚拟主机server{# 监听的IP和端口listen192.168.186.161:80;# 主机名server_name192.1868.186;# 访问日志文件存放路径access_loglogs/server1.access.log combined;location /{# 默认首页文件,顺序从左到右,如果找不到index.html文件,则查询index.htm文件作为首页文件indexindex.htmlindex.htm;# HTML网页文件存放的目录root/data0/htdocs/server1;}}# 第二个虚拟主机server{# 监听的IP和端口listen192.168.186.162:80;......}......}
从上面的配置文件中可以看出,一段server{......}
就是一个虚拟主机,如果要配置多个虚拟主机,建立多段server{}
配置即可,监听的IP和端口也可以不写IP地址,只写端口,把它配置成listen 80
,则表示监听该服务器上所有IP的80端口,可通过server_name区分不同的虚拟主机
配置机遇域名的虚拟主机:
只需要配置你的DNS服务器,将每个主机名映射到正确的IP地址,然后配置Nginx服务器,令其识别不同的主机名就可以了,这种虚拟主机技术,使很多虚拟主机可以共享同一个IP地址,有效的解决了IP地址不足的问题,所以,如果没有特殊要求使你必须用一个基于IP的虚拟主机,最好还是试用基于域名的虚拟主机
如下配置中,配置了三个虚拟主机,第一个虚拟主机表示所有对域名aaa.domain.com
的访问都由它来处理,第二个虚拟主机表示所有对域名bbb.otherdomain.com
的访问都由它来处理,第三个虚拟主机表示对域名www.domain.com、domain.com
以及除了aaa.domain.com
之外的所有*.domain.com
二级域名的访问都由它来处理,每个虚拟主机的网页文件分别存放在了不同的目录中,每个虚拟主机使用了不同的日志文件来记录访问日志
http{# 第一个虚拟主机server{# 监听的IP和端口listen192.168.186.161:80;# 主机名server_nameaaa.domain.com# 访问日志文件存放路径access_loglogs/aaa.domain.com.access.log combined;location /{# 默认首页文件,顺序从左到右,如果找不到index.html文件,则查询index.htm文件作为首页文件indexindex.htmlindex.htm;# HTML网页文件存放的目录root/data0/htdocs/aaa.domain.com;}}# 第二个虚拟主机server{# 监听的IP和端口listen192.168.186.161:80;# 主机名server_namebbb.otherdomain.com# 访问日志文件存放路径access_loglogs/bbb.otherdomain.com.access.log combined;location /{# 默认首页文件,顺序从左到右,如果找不到index.html文件,则查询index.htm文件作为首页文件indexindex.htmlindex.htm;# HTML网页文件存放的目录root/data0/htdocs/bbb.otherdomain.com;}}# 第三个虚拟主机server{# 监听的IP和端口listen192.168.186.161:80;# 主机名server_namewww.domain.comdomain.com*.domain.com# 访问日志文件存放路径access_loglogs/bbb.domain.com.access.log combined;location /{# 默认首页文件,顺序从左到右,如果找不到index.html文件,则查询index.htm文件作为首页文件indexindex.htmlindex.htm;# HTML网页文件存放的目录root/data0/htdocs/domain.com;}}}
4、Nginx日志文件的切割:
在生产环境中的服务器,由于访问日志文件增长速度非常快,日志太大会严重影响服务器效率,同时为了方便对日志进行分析计算,需要对日志文件进行定时切割,定时切割的方式有按月切割、按天切割、按小时切割等,最常用的是按天切割
Nginx不支持像Apache一样试用cronolog来轮转日志,但是可以采用以下方式来实现日志文件的切割:
mv /data1/logs/access.log /data1/logs/20090318.logkill -USR1 Nginx 主进程号
首先通过mv命令将日志文件重命名为/data1/logs/20090318.log
,然后发送kill-USR1
信号给Nginx的主进程号,让Nginx重新生成一个新的日志文件/data1/logs/access.log
,如果nginx.conf配置文件中使用了pid/usr/local/webserver/nginx/nginx.pid;
指令,指定了pid文件的存放路径,我们可以通过cat这个pid文件获得Nginx的主进程号,命令如下:
kill -USR1 `cat /usr/local/webserver/nginx/nginx.pid`
如果想每天定时切割日志,还需要借助crontab,我们可以写一个按天切割的日志,按年、月份目录存放日志的Shell脚本:
vi /usr/local/webserver/nginx/sbin/cut_nginx_log.sh
#!/bin/bash# 这个脚本需在每天的00:00运行# Nginx日志文件的存放路径logs_path="/data1/logs/"mkdir -p ${logs_path}$(date -d "yesterday" + "%Y")/$(date -d "yesterday" + "%m")/mv ${logs_path}access.log ${logs_path}$(date -d "yesterday" + "%Y")/$(date -d "yesterday" + "%m")/access_$(date -d "yesterday" + "%Y%m%d").logkill -USR1 `cat /usr/local/webserver/nginx/nginx.pid`
另外,配置crontab每天凌晨00:00定时执行这个脚本:
crontab -e
输入以下内容并保存:
00 00 * * * /bin/bash /usr/local/webserver/nginx/sbin/cut_nginx_log.sh
这个Shell脚本和Crontab配置主要实现的功能为:假设今天的日期为2009年5月19日,Nginx当前的日志文件为data1/logs/access.log,2009年5月20日00:00会执行cut_nginx_log.sh脚本,cut_nginx_log.sh脚本首先创建一个目录/data1/logs/2009/05/,然后将/data1/logs/access.log文件移动并重命名为/data1/logs/2009/05/access_20090519.log,在发送kill -USR1
信号给Nginx主进程号,告诉Nginx重新生成一个/data1/logs/access.log文件,2009年5月20日的日志记录在这个新生成的日志文件中,而/data1/logs/2009/05/access_20090519.log文件,就是2009年5月19日的日志文件
5、其它:
…
二、JVM:
1、面试题:
-
内存模型以及分区,需要详细到每个区放什么:
JVM分为堆区和栈区,还有方法区,初始化的对象放在堆里面,引用放在栈里面, class类信息常量池(static 常量和 static 变量)等放在方法区
new:
- **方法区:**主要是存储类信息,常量池(static 常量和 static 变量),编译后的代码(字 节码)等数据
- **堆:**初始化的对象,成员变量 (那种非 static 的变量),所有的对象实例和数组都要 在堆上分配
- **栈:**栈的结构是栈帧组成的,调用一个方法就压入一帧,帧上面存储局部变量表,操 作数栈,方法出口等信息,局部变量表存放的是 8 大基础类型加上一个应用类型,所 以还是一个指向地址的指针
- **本地方法栈:**主要为 Native 方法服务
- **程序计数器:**记录当前线程执行的行号
-
堆里面的分区:Eden,survival (from+ to),老年代,各自的特点:
堆里面分为新生代和老生代(Java8 取消了永久代,采用了 Metaspace),新生代包 含 Eden+Survivor 区,survivor 区里面分为 from 和 to 区,内存回收时,如果用的是复 制算法,从 from 复制到 to,当经过一次或者多次 GC 之后,存活下来的对象会被移动 到老年区,当 JVM 内存不够用的时候,会触发 Full GC,清理 JVM 老年区 当新生区满了之后会触发 YGC,先把存活的对象放到其中一个 Survice 区,然后进行垃圾清理。因为如果仅仅清理需要删除的对象,这样会导致内存碎 片,因此一般会把 Eden 进行完全的清理,然后整理内存。那么下次 GC 的时候, 就会使用下一个 Survive,这样循环使用。如果有特别大的对象,新生代放不下, 就会使用老年代的担保,直接放到老年代里面。因为 JVM 认为,一般大对象的存 活时间一般比较久远
-
对象创建方法,对象的内存分配,对象的访问定位:
new 一个对象
-
GC 的两种判定方法:
-
**引用计数法:**指的是如果某个地方引用了这个对象就+1,如果失效了就-1,当为 0 就 会回收但是 JVM 没有用这种方式,因为无法判定相互循环引用(A 引用 B,B 引用 A) 的情况
-
**引用链法:**通过一种 GC ROOT 的对象(方法区中静态变量引用的对象等-static 变 量)来判断,如果有一条链能够到达 GC ROOT 就说明,不能到达 GC ROOT 就说明 可以回收
-
-
SafePoint 是什么:
比如 GC 的时候必须要等到 Java线程都进入到 safepoint 的时候 VMThread 才能开始 执行 GC
- 循环的末尾(防止大循环的时候一直不进入 safepoint,而其他线程在等待它进入 safepoint)
- 方法返回前
- 调用方法的 call 之后
- 抛出异常的位置
-
GC 的三种收集方法:标记清除、标记整理、复制算法的原理与特点,分别用 在什么地方,如果让你优化收集方法,有什么思路:
先标记,标记完毕之后再清除,效率不高,会产生碎片
- **复制算法:**分为 8:1 的 Eden 区和 survivor 区,就是上面谈到的 YGC
- **标记整理:**标记完毕之后,让所有存活的对象向一端移动
-
GC 收集器有哪些?CMS 收集器与 G1 收集器的特点:
- **并行收集器:**串行收集器使用一个单独的线程进行收集,GC 时服务有停顿时间
- **串行收集器:**次要回收中使用多线程来执行
CMS 收集器是基于**”标记—清除“**算法实现的,经过多次标记才会被清除
G1 从**整体来看是基于“标记—整理”算法实现的收集器,从局部(两个 Region 之间) 上来看是基于“复制”**算法实现的
-
Minor GC 与 Full GC 分别在什么时候发生:
新生代内存不够用时候发生 MGC 也叫 YGC,JVM 内存不够的时候发生 FGC
-
几种常用的内存调试工具:jmap、jstack、jconsole、jhat:
jstack 可以看当前栈的情况,jmap 查看内存,jhat 进行 dump 堆的信息 mat(eclipse 的也要了解一下)
-
类加载的几个过程:
加载、验证、准备、解析、初始化。然后是使用和卸载了
通过全限定名来加载生成 class 对象到内存中,然后进行验证这个 class 文件,包括文 件格式校验、元数据验证,字节码校验等。准备是对这个对象分配内存。解析是将符 号引用转化为直接引用(指针引用),初始化就是开始执行构造器的代码
-
JVM 内存分哪几个区,每个区的作用是什么:
Java 虚拟机主要分为以下一个区:
方法区:
- 1)有时候也成为永久代,在该区内很少发生垃圾回收,但是并不代表不发生 GC,在这里 进行的 GC 主要是对方法区里的常量池和对类型的卸载
- 2)方法区主要用来存储已被虚拟机加载的类的信息、常量、静态变量和即时编译器编译后 的代码等数据
- 3)该区域是被线程共享的
- 4)方法区里有一个运行时常量池,用于存放静态编译产生的字面量和符号引用。该常量池 具有动态性,也就是说常量并不一定是编译时确定,运行时生成的常量也会存在这个常量 池中
虚拟机栈:
- 1)虚拟机栈也就是我们平常所称的栈内存,它为 java 方法服务,每个方法在执行的时候都会创建一个栈帧,用于存储局部变量表、操作数栈、动态链接和方法出口等信息
- 2)虚拟机栈是线程私有的,它的生命周期与线程相同
- 3)局部变量表里存储的是基本数据类型、returnAddress 类型(指向一条字节码指令的地址)和对象引用,这个对象引用有可能是指向对象起始地址的一个指针,也有可能是代表 对象的句柄或者与对象相关联的位置。局部变量所需的内存空间在编译器间确定
- 4)操作数栈的作用主要用来存储运算结果以及运算的操作数,它不同于局部变量表通过索 引来访问,而是压栈和出栈的方式
- 5)每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用,持有这个引用是为了 支持方法调用过程中的动态连接.动态链接就是将常量池中的符号引用在运行期转化为直接 引用
本地方法栈:
- 本地方法栈和虚拟机栈类似,只不过本地方法栈为 Native 方法服务
堆:
- Java 堆是所有线程所共享的一块内存,在虚拟机启动时创建,几乎所有的对象实例都在这 里创建,因此该区域经常发生垃圾回收操作
程序计数器:
- 内存空间小,字节码解释器工作时通过改变这个计数值可以选取下一条需要执行的字节码 指令,分支、循环、跳转、异常处理和线程恢复等功能都需要依赖这个计数器完成。该内 存区域是唯一一个 java 虚拟机规范没有规定任何 OOM 情况的区域
-
如和判断一个对象是否存活?(或者 GC 对象的判定方法):
判断一个对象是否存活有两种方法:
1、引用计数法:
-
所谓引用计数法就是给每一个对象设置一个引用计数器,每当有一个地方引用这个对象 时,就将计数器加一,引用失效时,计数器就减一。当一个对象的引用计数器为零时,说 明此对象没有被引用,也就是“死对象”,将会被垃圾回收
引用计数法有一个缺陷就是无法解决循环引用问题,也就是说当对象 A 引用对象 B,对象 B 又引用者对象 A,那么此时 A,B 对象的引用计数器都不为零,也就造成无法完成垃圾回 收,所以主流的虚拟机都没有采用这种算法
2、可达性算法(引用链法):
-
该算法的思想是:从一个被称为 GC Roots 的对象开始向下搜索,如果一个对象到 GC Roots 没有任何引用链相连时,则说明此对象不可用
在 java 中可以作为 GC Roots 的对象有以下几种:
- 虚拟机栈中引用的对象
- 方法区类静态属性引用的对象
- 方法区常量池引用的对象
- 本地方法栈 JNI 引用的对象
虽然这些算法可以判定一个对象是否能被回收,但是当满足上述条件时,一个对象比不一 定会被回收。当一个对象不可达 GC Root 时,这个对象并不会立马被回收,而是出于一个死缓的阶段,若要被真正的回收需要经历两次标记 如果对象在可达性分析中没有与 GC Root 的引用链,那么此时就会被第一次标记并且进行 一次筛选,筛选的条件是是否有必要执行 finalize()方法。当对象没有覆盖 finalize()方法或者已被虚拟机调用过,那么就认为是没必要的
如果该对象有必要执行 finalize()方法,那么这个对象将会放在一个称为 F-Queue 的对队 列中,虚拟机会触发一个 Finalize()线程去执行,此线程是低优先级的,并且虚拟机不会承 诺一直等待它运行完,这是因为如果 finalize()执行缓慢或者发生了死锁,那么就会造成 FQueue 队列一直等待,造成了内存回收系统的崩溃。GC 对处于 F-Queue 中的对象进行 第二次被标记,这时,该对象将被移除”即将回收”集合,等待回收
-
-
简述 java 垃圾回收机制:
在 java 中,程序员是不需要显示的去释放一个对象的内存的,而是由虚拟机自行执行。在 JVM 中,有一个垃圾回收线程,它是低优先级的,在正常情况下是不会执行的,只有在虚 拟机空闲或者当前堆内存不足时,才会触发执行,扫面那些没有被任何引用的对象,并将 它们添加到要回收的集合中,进行回收
-
.java 中垃圾收集的方法有哪些:
标记-清除:
- 这是垃圾收集算法中最基础的,根据名字就可以知道,它的思想就是标记哪些要被 回收的对象,然后统一回收。这种方法很简单,但是会有两个主要问题:1.效率不 高,标记和清除的效率都很低;2.会产生大量不连续的内存碎片,导致以后程序在 分配较大的对象时,由于没有充足的连续内存而提前触发一次 GC 动作
复制算法:
-
为了解决效率问题,复制算法将可用内存按容量划分为相等的两部分,然后每次只 使用其中的一块,当一块内存用完时,就将还存活的对象复制到第二块内存上,然 后一次性清楚完第一块内存,再将第二块上的对象复制到第一块。但是这种方式,内存的代价太高,每次基本上都要浪费一般的内存
于是将该算法进行了改进,内存区域不再是按照 1:1 去划分,而是将内存划分为 8:1:1 三部分,较大那份内存交 Eden 区,其余是两块较小的内存区叫 Survior 区。 每次都会优先使用 Eden 区,若 Eden 区满,就将对象复制到第二块内存区上,然 后清除 Eden 区,如果此时存活的对象太多,以至于 Survivor 不够时,会将这些对 象通过分配担保机制复制到老年代中。(java 堆又分为新生代和老年代)
标记-整理:
- 该算法主要是为了解决标记-清除,产生大量内存碎片的问题;当对象存活率较高 时,也解决了复制算法的效率问题。它的不同之处就是在清除对象的时候现将可回 收对象移动到一端,然后清除掉端边界以外的对象,这样就不会产生内存碎片了
分代收集:
- 现在的虚拟机垃圾收集大多采用这种方式,它根据对象的生存周期,将堆分为新生 代和老年代。在新生代中,由于对象生存期短,每次回收都会有大量对象死去,那么这时就采用复制算法。老年代里的对象存活率较高,没有额外的空间进行分配担 保,所以可以使用标记-整理 或者 标记-清除
-
Java 内存模型:
Java 内存模型(JMM)是线程间通信的控制机制.JMM 定义了主内存和线程之间抽象关系。 线程之间的共享变量存储在主内存(main memory)中,每个线程都有一个私有的本地 内存(local memory),本地内存中存储了该线程以读/写共享变量的副本。本地内存是 JMM 的一个抽象概念,并不真实存在。它涵盖了缓存,写缓冲区,寄存器以及其他的硬 件和编译器优化。Java 内存模型的抽象示意图如下:
从上图来看,线程 A 与线程 B 之间如要通信的话,必须要经历下面 2 个步骤:
- 1)首先,线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中去
- 2)然后,线程 B 到主内存中去读取线程 A 之前已更新过的共享变量
-
Java 类加载过程:
Java 类加载需要经历一下 7 个过程:
加载:
- 加载时类加载的第一个过程,在这个阶段,将完成一下三件事情:
- 1)通过一个类的全限定名获取该类的二进制流
- 2)将该二进制流中的静态存储结构转化为方法去运行时数据结构
- 3)在内存中生成该类的 Class 对象,作为该类的数据访问入口
验证:
- 验证的目的是为了确保 Class 文件的字节流中的信息不回危害到虚拟机.在该阶段主要完成 以下四钟验证:
- 1)**文件格式验证:**验证字节流是否符合 Class 文件的规范,如主次版本号是否在当前虚拟 机范围内,常量池中的常量是否有不被支持的类型
- 2)**元数据验证:**对字节码描述的信息进行语义分析,如这个类是否有父类,是否集成了不 被继承的类等
- 3)**字节码验证:**是整个验证过程中最复杂的一个阶段,通过验证数据流和控制流的分析, 确定程序语义是否正确,主要针对方法体的验证。如:方法中的类型转换是否正确,跳转 指令是否正确等
- 4)**符号引用验证:**这个动作在后面的解析过程中发生,主要是为了确保解析动作能正确执行
准备:
-
准备阶段是为类的静态变量分配内存并将其初始化为默认值,这些内存都将在方法区中进 行分配。准备阶段不分配类中的实例变量的内存,实例变量将会在对象实例化时随着对象 一起分配在 Java 堆中
// 在准备阶段 value 初始值为 0 。在初始化阶段才会变为 123public static int value=123;
解析:
- 该阶段主要完成符号引用到直接引用的转换动作。解析动作并不一定在初始化动作完成之 前,也有可能在初始化之后
初始化:
- 初始化时类加载的最后一步,前面的类加载过程,除了在加载阶段用户应用程序可以通过 自定义类加载器参与之外,其余动作完全由虚拟机主导和控制。到了初始化阶段,才真正 开始执行类中定义的 Java 程序代码
- 加载时类加载的第一个过程,在这个阶段,将完成一下三件事情:
-
简述 Java 类加载机制:
虚拟机把描述类的数据从 Class 文件加载到内存,并对数据进行校验,解析和初始化,最 终形成可以被虚拟机直接使用的 java 类型
-
类加载器双亲委派模型机制:
当一个类收到了类加载请求时,不会自己先去加载这个类,而是将其委派给父类,由父类 去加载,如果此时父类不能加载,反馈给子类,由子类去完成类的加载
-
什么是类加载器,类加载器有哪些:
实现通过类的权限定名获取该类的二进制字节流的代码块叫做类加载器
主要有一下四种类加载器:
- 1)启动类加载器(Bootstrap ClassLoader)用来加载 java 核心类库,无法被 java 程序直接 引用
- 2)扩展类加载器(extensions class loader):它用来加载 Java 的扩展库。Java 虚拟机的 实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类
- 3)系统类加载器(system class loader):它根据 Java 应用的类路径(CLASSPATH) 来加载 Java 类。一般来说,Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它
- 4)用户自定义类加载器,通过继承 java.lang.ClassLoader 类的方式实现
-
简述 java 内存分配与回收策率以及 Minor GC 和 Major GC:
-
1)对象优先在堆的 Eden 区分配
-
2)大对象直接进入老年代
-
3)长期存活的对象将直接进入老年代
当 Eden 区没有足够的空间进行分配时,虚拟机会执行一次 Minor GC.Minor Gc 通 常发生在新生代的 Eden 区,在这个区的对象生存期短,往往发生 Gc 的频率较高, 回收速度比较快;Full Gc/Major GC 发生在老年代,一般情况下,触发老年代 GC 的时候不会触发 Minor GC,但是通过配置,可以在 Full GC 之前进行一次 Minor GC 这样可以加快老年代的回收速度
-