标签：情况下   shc   引入   精度   val   一个   ++   generate   ade   

1.eclipse什么时候编译java类文件

2.在同一包中的类可以相互引用，无需用import语句

3.在Java eclipse用ALT输入特殊符号

4.if else等语句，什么时候可以不加括号 

5.HashMap桶中链表转红黑树为什么选择数字8？

6.++i和i++的区别 

7.nanoTime vs currentTimeMillis 比较

1.eclipse什么时候编译java类文件

1）第一次创建类的时候会编译一次

2） 每次修改了这个文件保存之后会编译一次

2.在同一包中的类可以相互引用，无需用import语句

（1）引入包中的类(如果我们只想引入某个包中的类)
import java.io.File;
（2）引入整个包

　　import java.io.*;（①这样虽然方便，但是当导入包中所有的类时，java编译器就会用额外的内存来存储包中类和方法的名字，以便跟踪这个包中所有的元素，这在pc机上没有太大的性能差异。然而当在手持设备上，一般的手持设备内存都比较小，这种方式就不太好了，更适合第一种方式想引用哪个类就具体引用哪个②当通过网络远程加载一个类时，如果它导入了一包中所有的类，那么在加载的时候就会把所有的类和方法加载到本地来，这就会造成java程序执行时间上的延迟。所以只有当需要导入这个包中很多类的时候，再用这种方式。）
（3）在同一包中的类可以互相引用，无需import语句（非要手动加入也不会报错）
　注意：java.lang包是自动引入的，不需要显式的加import引入。因此可以直接引用System、String 

3.在Java eclipse代码注释后如何输入n的3次方,就是n的右上角的数字3如何写上出?

平方的输入是按住alt后不放，依次按小键盘上的178三个键,放开所有按键，就会得到² 同样，立方还是上面的方法，按小键盘上的179

扩展：详见：https://www.cnblogs.com/lukelook/p/6840113.html#t4

4.if else等语句，什么时候可以不加括号

今天在写代码的时候无意间发现了 if 和 else 后面不用带括号

if (Boolean)
         true
else
         false

有大括号的时候
大括号里面所有的 都归if管。只有条件为真的时候 才会执行。
没有大括号的时候 只有下面的一句归if管，

也就是说 当只有一句的时候 大括号可以省略 其它的 没区别。

这种情况，没多久就忘了，再记录一次，加深印象。不然读代码的时候让人很疑惑。

今天分享这个就是想到java规范里面很多都有if后面即使一句都要使用大括号，不只是直观，很多时候能帮我们避免很多错误。以后编程一定要尽量根据规范进行。

看如下代码：

案例1：

if(Character.isLowerCase(c))
    if(count[c-‘a‘]==1)
        return i;
else
    if(count[c-‘A‘+26]==1)
        return i;

预期的执行效果

if(Character.isLowerCase(c)){
    if(count[c-‘a‘]==1)
        return i;
}
else{
    if(count[c-‘A‘+26]==1)
        return i;
}

而其实编译后为

if(Character.isLowerCase(c))
    if(count[c-‘a‘]==1)
        return i;
    else
        if(count[c-‘A‘+26]==1)
            return i;

案例2：

if (status == null)
       x=1;y=2;z=3;

预期的执行效果

if (status == null){
       x=1;y=2;z=3;
}

而实际编译后为

if (status == null)
      { x=1};
y=2;
z=3; 

所以说，为了防止类似错误发生，以后一律统统按规范加括号，这样就OK了 

5.HashMap桶中链表转红黑树为什么选择数字8？

.在JDK8及以后的版本中，HashMap引入了红黑树结构，其底层的数据结构变成了数组+链表或数组+红黑树。添加元素时，若桶中链表个数超过8，链表会转换成红黑树。之前有写过篇幅分析选择数字8的原因，觉得不够严谨。最近重新翻了一下HashMap的源码，发现其源码中有这样一段注释：

Because TreeNodes are about twice the size of regular nodes, we use them only when bins contain enough nodes to warrant use (see TREEIFY_THRESHOLD). And when they become too small (due to removal or resizing) they are converted back to plain bins. In usages with well-distributed user hashCodes, tree bins are

rarely used. Ideally, under random hashCodes, the frequency of nodes in bins follows a Poisson distribution (http://en.wikipedia.org/wiki/Poisson_distribution) with a parameter of about 0.5 on average for the default resizing threshold of 0.75, although with a large variance because of resizing granularity. Ignoring variance, the expected occurrences of list size k are (exp(-pow(0.5, k) / factorial(k)). The first values are:

0: 0.60653066

1: 0.30326533

2: 0.07581633

3: 0.01263606

4: 0.00157952

5: 0.00015795

6: 0.00001316

7: 0.00000094

8: 0.00000006

more: less than 1 in ten million

翻译过来大概的意思是：理想情况下使用随机的哈希码，容器中节点分布在hash桶中的频率遵循泊松分布(具体可以查看http://en.wikipedia.org/wiki/Poisson_distribution)，按照泊松分布的计算公式计算出了桶中元素个数和概率的对照表，可以看到链表中元素个数为8时的概率已经非常小，再多的就更少了，所以原作者在选择链表元素个数时选择了8，是根据概率统计而选择的。

6.++i 和 i++的区别 

前者先自增再使用，

后者先使用再自增；

public class ClassTest {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        int i = 0;
        int j = 0;
        
        System.out.println(++i);
        System.out.println(j++);
  　　　 System.out.println(j);
　　　　　
    }

}

输出结果为

1
0
1

另外 i++ （i = i + 1)不是原子操作，而 i = 1 是原子操作。

7.nanoTime vs currentTimeMillis 比较

1.currentTimeMillis返回的是系统当前时间和1970-01-01之前间隔时间的毫秒数，如果系统时间固定则方法返回值也是一定的（这么说是为了强调和nanoTime的区别），精确度是毫秒级别的；

nanoTime的返回值本身则没有什么意义，因为它基于的时间点是随机的，甚至可能是一个未来的时间，所以返回值可能为负数。但是其精确度为纳秒，相对高了不少。

2.currentTimeMillis不仅可以用来计算代码执行消耗的时间 ，也可以和Date类方便的转换。而nanoTime则不行
可以这么说吧，currentTimeMillis是一个时钟，而nanoTime是一个计时器，你可以用时钟来计算时间差，也可以用来单纯的看时间，但是作为计时器的nanoTime则只能用来计算时间差，好在优点是精确度高

3.currentTimeMillis是基于系统时间的，也就是说如果你再程序执行期间更改了系统时间则结果就会出错，而nanoTime是基于CPU的时间片来计算时间的，无法人为干扰
前面说了nanoTime基于的时间点是随机的，但是对于同一个JVM里，不同地方使用到的基点时间是一样的

此方法只能用于测量已过的时间，与系统或钟表时间的其他任何时间概念无关。返回值表示从某一固定但任意的时间算起的毫微秒数（或许从以后算起，所以该值可能为负）。此方法提供毫微秒的精度，但不是必要的毫微秒的准确度。它对于值的更改频率没有作出保证。在取值范围大于约 292 年（263 毫微秒）的连续调用的不同点在于：由于数字溢出，将无法准确计算已过的时间。

public class ClassTest {

    public static void main(String[] args) {
        // TODO Auto-generated method stub
        System.out.println("Test for currentTimeMillis");
        for (int i = 0; i ) {            
            System.out.println(i + " : " + System.currentTimeMillis());            
        }
        
        System.out.println("Test for nanoTime");
        for (int i = 0; i ) {            
            System.out.println(i + " : " + System.nanoTime());            
        }
                

    }

}

输出结果

Test for currentTimeMillis
0 : 1588297108093
1 : 1588297108093
2 : 1588297108093
3 : 1588297108094
4 : 1588297108094
Test for nanoTime
0 : 10509981773594
1 : 10509981950048
2 : 10509982119115
3 : 10509982337424
4 : 10509982888533

java基础点

标签：情况下   shc   引入   精度   val   一个   ++   generate   ade   

原文地址：https://www.cnblogs.com/lukelook/p/11274053.html