叨叨两句
搞定~
牛客网——java专项练习027
1
java中下面哪个能创建并启动线程()
public class MyRunnable implements Runnable { public void run() { //some code here } }
正确答案: C
new Runnable(MyRunnable).start()
new Thread(MyRunnable).run()
new Thread(new MyRunnable()).start()
new MyRunnable().start()
首先:创建并启动线程的过程为:定义线程—》实例化线程—》启动线程。一 、定义线程: 1、扩展java.lang.Thread类。 2、实现java.lang.Runnable接口。二、实例化线程: 1、如果是扩展java.lang.Thread类的线程,则直接new即可。 2、如果是实现了java.lang.Runnable接口的类,则用Thread的构造方法: Thread(Runnable target) Thread(Runnable target, String name) Thread(ThreadGroup group, Runnable target) Thread(ThreadGroup group, Runnable target, String name) Thread(ThreadGroup group, Runnable target, String name, long stackSize)所以A、D的实例化线程错误。三、启动线程: 在线程的Thread对象上调用start()方法,而不是run()或者别的方法。所以B的启动线程方法错误。
2
下面哪个不对?
正确答案: C 你的答案: C (正确)RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java Virtual Machine.
-
method is not required to declare in its throws clause any subclasses of RuntimeExeption that might be thrown during the execution of the method but not caught
An RuntimeException is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.
NullPointerException is one kind of RuntimeException
运行时异常: 都是RuntimeException类及其子类异常,如NullPointerException(空指针异常)、IndexOutOfBoundsException(下标越界异常)等,这些异常是不检查异常,程序中可以选择捕获处理,也可以不处理。这些异常一般是由程序逻辑错误引起的,程序应该从逻辑角度尽可能避免这类异常的发生。 运行时异常的特点是Java编译器不会检查它,也就是说,当程序中可能出现这类异常,即使没有用try-catch语句捕获它,也没有用throws子句声明抛出它,也会编译通过。 非运行时异常 (编译异常): 是RuntimeException以外的异常,类型上都属于Exception类及其子类。从程序语法角度讲是必须进行处理的异常,如果不处理,程序就不能编译通过。如IOException、SQLException等以及用户自定义的Exception异常,一般情况下不自定义检查异常。
3
有以下程序段, 则下面正确的选项是()
public class MyThead extends Thread{ public static void main(String[] args) { MyThead t=new MyThead(); MyThead s=new MyThead(); t.start(); System.out.println("one."); s.start(); System.out.println("two."); } public void run() { System.out.println("Thread"); }}
正确答案: B C D
编译失败
程序运行可能结果为:
one.
Threadtwo.Thread程序运行可能结果是:
one.
two.ThreadThread程序运行结果不稳定
start()是开启线程,等待获得时间片,一到获得时间片就执行。所以可能一开启就获得了时间片执行,也有可能等到two输出后才获得了时间片。所以BC都可能,所以D也正确。
4
在Java语言中,下列关于字符集编码(Character set encoding)和国际化(i18n)的问题,哪些是正确的?
正确答案: C D每个中文字符占用2个字节,每个英文字符占用1个字节
假设数据库中的字符是以GBK编码的,那么显示数据库数据的网页也必须是GBK编码的。
Java的char类型,通常以UTF-16 Big Endian的方式保存一个字符。
实现国际化应用常用的手段是利用ResourceBundle类
A 显然是错误的,Java一律采用Unicode编码方式,每个字符无论中文还是英文字符都占用2个字节。B 也是不正确的,不同的编码之间是可以转换的,通常流程如下:将字符串S以其自身编码方式分解为字节数组,再将字节数组以你想要输出的编码方式重新编码为字符串。例:String newUTF8Str = new String(oldGBKStr.getBytes("GBK"), "UTF8");C 是正确的。Java虚拟机中通常使用UTF-16的方式保存一个字符D 也是正确的。ResourceBundle能够依据Local的不同,选择性的读取与Local对应后缀的properties文件,以达到国际化的目的。
很多人都把Unicode编码挂在嘴边,其实咱们现实生活中遇到的编码基本都是Unicode的因为Unicode兼容了大多数老版本的编码规范例如 ASCIIUnicode编码定义了这个世界上几乎所有字符(就是你眼睛看到的长那个样子的符号)的数字表示也就是说Unicode为每个字符发了一张身份证,这张身份证上有一串唯一的数字ID确定了这个字符在这个纷乱世界上存在的唯一性。Unicode给这串数字ID起了个名字叫[码点](Code Point)而很多人说的编码其实是想表达[Unicode转换格式](即UTF,Unicode Transformation Formats)有没有觉得眼前一亮豁然开朗?没错 这就是我们看到的UTF-8/UTF-16/UTF-32的前缀来源这个[Unicode转换格式]的存在是为了解决[码点]在计算机中的二进制表现形式而设计的毕竟我们的机内表示涉及存储位宽,兼容古老编码格式,码点是数值过大的罕见字符等问题[码点]经过映射后得到的二进制串的转换格式单位称之为[码元](Code Unit)。也就是说如果有一种UTF的码点二进制表示有n字节,其码元为8位(1个byte),那么其拥有码元n个。每种UTF的码元都不同,其宽度被作为区分写在了UTF的后缀——这就是UTF-8/UTF-16/UTF-32的由来。UTF-8的码元是8位的,UTF-16的码元是16位的。大部分的编程语言采用16位的码元作为机内表示。这就是我们在各种语言中调用获取一个字符串中character的数量时会出现这么多混乱的原因。事实上我们调用这些方法时取得的不是字符个数,而是码元个数!一旦我们的字符串中包含了位于基本平面之外的码点,那么就会需要更多的码元来表示,这个时候就会出现测试时常见的困惑——为何return的字符数比实际字符数要多?所以实际写代码时要特别注意这个问题。采取不同的映射方式可以得到不同格式的二进制串,但是他们背后所表示的[码点]永远是一致的就好像你换身份证但是身份证号不变一样。由于平时人们误把[转换格式]也称为[编码],所以造成今天Unicode/UTF傻傻分不清楚且遣词造句运用混乱的悲桑局面。Unicode 编码 发展到今天 扩展到了 21 位(从 U+0000 到 U+10FFFF )。这一点很重要: Unicode 不是 16 位的编码, 它是 21 位的。这 21 位提供了 1,114,112 个码点,其中,只有大概 10% 正在使用,所以还有相当大的扩充空间。编码空间被分成 17 个平面(plane),每个平面有 65,536 个字符(正好填充2个字节,16位)。0 号平面叫做「基本多文种平面」( BMP, Basic Multilingual Plane ),涵盖了几乎所有你能遇到的字符,除了 emoji(emoji位于1号平面 - -)。其它平面叫做补充平面,大多是空的。总结一下各种编码格式的特质:UTF-32最清楚明了的一个 UTF 就是 UTF-32 :它在每个码点上使用整 32 位。32 大于 21,因此每一个 UTF-32 值都可以直接表示对应的码点。尽管简单,UTF-32却几乎从来不在实际中使用,因为每个字符占用 4 字节太浪费空间了。UTF-16 以及「代理对」( Surrogate Pairs )的概念UTF-16要常见得多,它是根据有 16 位固定长度的码元( code units )定义的。UTF-16 本身是一种长度可变的编码。基本多文种平面(BMP)中的每一个码点都直接与一个码元相映射。鉴于 BMP 几乎囊括了所有常见字符,UTF-16 一般只需要 UTF-32 一半的空间。其它平面里很少使用的码点都是用两个 16 位的码元来编码的,这两个合起来表示一个码点的码元就叫做代理对( surrogate pair )。UTF-8UTF-8 使用一到四个字节来编码一个码点。从 0 到 127 的这些码点直接映射成 1 个字节(对于只包含这个范围字符的文本来说,这一点使得 UTF-8 和 ASCII 完全相同)。接下来的 1,920 个码点映射成 2 个字节,在 BMP 里所有剩下的码点需要 3 个字节。Unicode 的其他平面里的码点则需要 4 个字节。UTF-8 是基于 8 位的码元的,因此它并不需要关心字节顺序(不过仍有一些程序会在 UTF-8 文件里加上多余的 BOM)。有效率的空间使用(仅就西方语言来讲),以及不需要操心字节顺序问题使得 UTF-8 成为存储和交流 Unicode 文本方面的最佳编码。它也已经是文件格式、网络协议以及 Web API 领域里事实上的标准了。我们的JVM中保存码点是UTF16的转换格式,从char的位宽为16位也可以看得出来。由于绝大部分编码的码点位于基本平面,所以使用16位可以几乎表示所有常用字符。这就是许多语言编译器或运行时都使用UTF16的原因。英文在使用UTF16时也是2字节表示的。当我们想要使用其他平面的字符时,码元超过2个字节,就需要使用代理对在语言中的特定表示方式,譬如‘\U112233’之类的。使用UTF8时,常用的Alphabet和Numeric都在前127字节,被有效率地用一个字节表示。而我们的中文由于排在1920个码点之后,所以使用3个字节表示,这方面就比UTF16转换格式耗费更多空间。最后,不论使用哪种UTF转换格式,都是程序员自己可以选择的一种表达方式而已。我们可以通过Java方便的API进行自如转换