服务器提了一个问题，我们正在紧张地撰写答案...10:56 提问
JDK8构建报错了，哪位大神帮忙看下原因？
我的代码是从java.net网站下载的，名称为openjdk-8-src-b132-03_mar_2014.zip
CPU:i54469
OS:Ubuntu 15.04
执行CONFIGURE之前需要 unset JAVA_TOOL_OPTIONS
configure执行成功后，运行下面语句报错了，具体错误请看标黄的部分
/Desktop/openjdk$ make CONF=linux-x86_64-normal-server-fastdebug
Building 'linux-x86_64-normal-server-fastdebug' (matching CONF=linux-x86_64-normal-server-fastdebug)
Building OpenJDK for target 'default' in configuration 'linux-x86_64-normal-server-fastdebug'
Starting langtools
Finished langtools (build time 00:00:00)
Starting hotspot
make[2]: warning: -jN forced in submake: disabling jobserver mode.
INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
INFO: ALT_OBJCOPY=/usr/bin/objcopy
INFO: /usr/bin/objcopy cmd found so will create .debuginfo files.
INFO: STRIP_POLICY=min_strip
INFO: ZIP_DEBUGINFO_FILES=1
INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
INFO: ALT_OBJCOPY=/usr/bin/objcopy
INFO: /usr/bin/objcopy cmd found so will create .debuginfo files.
INFO: STRIP_POLICY=min_strip
INFO: ZIP_DEBUGINFO_FILES=1/usr/bin/make: invalid option -- '/'/usr/bin/make: invalid option -- 'a'/usr/bin/make: invalid option -- '/'/usr/bin/make: invalid option -- 'c'Usage: make [options] [target] ...Options:
Ignored for compatibility.
-B, --always-make
Unconditionally make all targets.
-C DIRECTORY, --directory=DIRECTORY
Change to DIRECTORY before doing anything.
Print lots of debugging information.
--debug[=FLAGS]
Print various types of debugging information.
-e, --environment-overrides
Environment variables override makefiles.
--eval=STRING
Evaluate STRING as a makefile statement.
-f FILE, --file=FILE, --makefile=FILE
Read FILE as a makefile.
-h, --help
Print this message and exit.
-i, --ignore-errors
Ignore errors from recipes.
-I DIRECTORY, --include-dir=DIRECTORY
Search DIRECTORY for included makefiles.
-j [N], --jobs[=N]
Allow N infinite jobs with no arg.
-k, --keep-going
Keep going when some targets can't be made.
-l [N], --load-average[=N], --max-load[=N]
Don't start multiple jobs unless load is below N.
-L, --check-symlink-times
Use the latest mtime between symlinks and target.
-n, --just-print, --dry-run, --recon
Don't act just print them.
-o FILE, --old-file=FILE, --assume-old=FILE
Consider FILE to be very old and don't remake it.
-O[TYPE], --output-sync[=TYPE]
Synchronize output of parallel jobs by TYPE.
-p, --print-data-base
Print make's internal database.
-q, --question
R exit status says if up to date.
-r, --no-builtin-rules
Disable the built-in implicit rules.
-R, --no-builtin-variables
Disable the built-in variable settings.
-s, --silent, --quiet
Don't echo recipes.
-S, --no-keep-going, --stop
Turns off -k.
-t, --touch
Touch targets instead of remaking them.
Print tracing information.
-v, --version
Print the version number of make and exit.
-w, --print-directory
Print the current directory.
--no-print-directory
Turn off -w, even if it was turned on implicitly.
-W FILE, --what-if=FILE, --new-file=FILE, --assume-new=FILE
Consider FILE to be infinitely new.
--warn-undefined-variables
Warn when an undefined variable is referenced.
This program built for x86_64-pc-linux-gnu
Report bugs to
make[5]: *** [ad_stuff] Error 2
/home/dxt/Desktop/openjdk/hotspot/make/linux/makefiles/top.make:91: recipe for target 'ad_stuff' failed
/home/dxt/Desktop/openjdk/hotspot/make/linux/Makefile:289: recipe for target 'fastdebug' failed
make[4]: *** [fastdebug] Error 2
Makefile:216: recipe for target 'generic_build2' failed
make[3]: *** [generic_build2] Error 2
Makefile:167: recipe for target 'fastdebug' failed
make[2]: *** [fastdebug] Error 2
HotspotWrapper.gmk:44: recipe for target '/home/dxt/Desktop/openjdk/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp' failed
make[1]: *** [/home/dxt/Desktop/openjdk/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp] Error 2
/home/dxt/Desktop/openjdk//make/Main.gmk:108: recipe for target 'hotspot-only' failed
make: *** [hotspot-only] Error 2
dxt@dxt-All-Series:~/Desktop/openjdk$ pon dsl-provider
Plugin rp-pppoe.so loaded.
按赞数排序
确切的说是openjdk/hotspot/make/linux/makefiles/top.make的第91行报错了
86 $(Cached_plat): $(Plat_File)
$(CDG) cp $(Plat_File) $(Cached_plat)
89 # make AD files as necessary
90 ad_stuff: $(Cached_plat) $(adjust-mflags)
@$(MAKE) -f adlc.make $(MFLAGS-adjusted)
93 # generate JVMTI files from the spec
94 jvmti_stuff: $(Cached_plat) $(adjust-mflags)
@$(MAKE) -f jvmti.make $(MFLAGS-adjusted)
请问一下，有解决的方法没有？我也碰到了，但是用virtualbox 安装的32位14.04ubuntu下，32 位openjdk8,一点问题都没有，可以编通。真机64位ubuntu 16.04就是不可以
你jdk8版本太老了，但是你系统又比较新（很多工具，例如make也是最新的），导致很多不匹配。解决办法换成最新版本的jdk8吧。具体方法：hg clone
&& sh get_source.sh. 后面就是一样的。
其他相似问题后使用快捷导航没有帐号？
查看: 148|回复: 0
JDK8对并发的新支持
金牌会员, 积分 2916, 距离下一级还需 84 积分
论坛徽章:26
1. LongAdder和AtomicLong类似的使用方式，但是性能比AtomicLong更好。LongAdder与AtomicLong都是使用了原子操作来提高性能。但是LongAdder在AtomicLong的基础上进行了热点分离，热点分离类似于有锁操作中的减小锁粒度，将一个锁分离成若干个锁来提高性能。在无锁中，也可以用类似的方式来增加CAS的成功率，从而提高性能。LongAdder原理图：AtomicLong的实现方式是内部有个value 变量，当多线程并发自增，自减时，均通过CAS 指令从机器指令级别操作保证并发的原子性。唯一会制约AtomicLong高效的原因是高并发，高并发意味着CAS的失败几率更高， 重试次数更多，越多线程重试，CAS失败几率又越高，变成恶性循环，AtomicLong效率降低。而LongAdder将把一个value拆分成若干cell，把所有cell加起来，就是value。所以对LongAdder进行加减操作，只需要对不同的cell来操作，不同的线程对不同的cell进行CAS操作，CAS的成功率当然高了（试想一下3+2+1=6，一个线程3+1，另一个线程2+1，最后是8，LongAdder没有乘法除法的API）。可是在并发数不是很高的情况，拆分成若干的cell，还需要维护cell和求和，效率不如AtomicLong的实现。LongAdder用了巧妙的办法来解决了这个问题。初始情况，LongAdder与AtomicLong是相同的，只有在CAS失败时，才会将value拆分成cell，每失败一次，都会增加cell的数量，这样在低并发时，同样高效，在高并发时，这种“自适应”的处理方式，达到一定cell数量后，CAS将不会失败，效率大大提高。LongAdder是一种以空间换时间的策略。2. CompletableFuture实现CompletionStage接口（40余个方法），大多数方法多数应用在函数式编程中。并且支持流式调用CompletableFuture是Java 8中对Future的增强版简单实现：import java.pletableF
public class AskThread implements Runnable {
&&CompletableFuture&Integer& re =
&&public AskThread(CompletableFuture&Integer& re) {
& & this.re =
&&}
&&@Override
&&public void run() {
& & int myRe = 0;
& & try {
& && &myRe = re.get() * re.get();
& & } catch (Exception e) {
& & }
& & System.out.println(myRe);
&&}
&&public static void main(String[] args) throws InterruptedException {
& & final CompletableFuture&Integer& future = new CompletableFuture&Integer&();
& & new Thread(new AskThread(future)).start();
& & // 模拟长时间的计算过程
& & Thread.sleep(1000);
& & // 告知完成结果
& & plete(60);
&&}
}复制代码Future最令人诟病的就是要等待，要自己去检查任务是否完成了，在Future中，任务完成的时间是不可控的。而CompletableFuture的最大改进在于，任务完成的时间也开放了出来。plete(60);用来设置完成时间。CompletableFuture的异步执行：public static Integer calc(Integer para) {
& & try {
& && &// 模拟一个长时间的执行
& && &Thread.sleep(1000);
& & } catch (InterruptedException e) {
& & }
& & return para *
&&}
&&public static void main(String[] args) throws InterruptedException,
& && &ExecutionException {
& & final CompletableFuture&Integer& future = CompletableFuture
& && &&&.supplyAsync(() -& calc(50));
& & System.out.println(future.get());
&&}复制代码CompletableFuture的流式调用：public static Integer calc(Integer para) {
& & try {
& && &// 模拟一个长时间的执行
& && &Thread.sleep(1000);
& & } catch (InterruptedException e) {
& & }
& & return para *
&&}
&&public static void main(String[] args) throws InterruptedException,
& && &ExecutionException {
& & CompletableFuture&Void& fu = CompletableFuture
& && &&&.supplyAsync(() -& calc(50))
& && &&&.thenApply((i) -& Integer.toString(i))
& && &&&.thenApply((str) -& &\&& + str + &\&&)
& && &&&.thenAccept(System.out::println);
& & fu.get();
&&}复制代码组合多个CompletableFuture：public static Integer calc(Integer para) {
& & return para / 2;
&&}
&&public static void main(String[] args) throws InterruptedException,
& && &ExecutionException {
& & CompletableFuture&Void& fu = CompletableFuture
& && &&&.supplyAsync(() -& calc(50))
& && &&&.thenCompose(
& && && && &(i) -& CompletableFuture.supplyAsync(() -& calc(i)))
& && &&&.thenApply((str) -& &\&& + str + &\&&)
& && &&&.thenAccept(System.out::println);
& & fu.get();
&&}复制代码这几个例子更多是侧重Java8的一些新特性，这里就简单举下例子来说明特性，就不深究了。CompletableFuture跟性能上关系不大，更多的是为了支持函数式编程，在功能上的增强。当然开放了完成时间的设置是一大亮点。3. StampedLock在上一篇中刚刚提到了锁分离，而锁分离的重要的实现就是ReadWriteLock。而StampedLock则是ReadWriteLock的一个改进。StampedLock与ReadWriteLock的区别在于，StampedLock认为读不应阻塞写，StampedLock认为当读写互斥的时候，读应该是重读，而不是不让写线程写。这样的设计解决了读多写少时，使用ReadWriteLock会产生写线程饥饿现象。所以StampedLock是一种偏向于写线程的改进。StampedLock示例：import java.util.concurrent.locks.StampedL
public class Point {
&&private double x,
&&private final StampedLock sl = new StampedLock();
&&void move(double deltaX, double deltaY) { // an exclusively locked method
& & long stamp = sl.writeLock();
& & try {
& && &x += deltaX;
& && &y += deltaY;
& & } finally {
& && &sl.unlockWrite(stamp);
& & }
&&}
&&double distanceFromOrigin() { // A read-only method
& & long stamp = sl.tryOptimisticRead();
& & double currentX = x, currentY =
& & if (!sl.validate(stamp)) {
& && &stamp = sl.readLock();
& && &try {
& && &&&currentX =
& && &&&currentY =
& && &} finally {
& && &&&sl.unlockRead(stamp);
& && &}
& & }
& & return Math.sqrt(currentX * currentX + currentY * currentY);
&&}
}复制代码上述代码模拟了写线程和读线程， StampedLock根据stamp来查看是否互斥，写一次stamp变增加某个值tryOptimisticRead()就是刚刚所说的读写不互斥的情况。每次读线程要读时，会先判断if (!sl.validate(stamp))validate中会先查看是否有写线程在写，然后再判断输入的值和当前的 stamp是否相同，即判断是否读线程将读到最新的数据。如果有写线程在写，或者 stamp数值不同，则返回失败。如果判断失败，当然可以重复的尝试去读，在示例代码中，并没有让其重复尝试读，而采用的是将乐观锁退化成普通的读锁去读，这种情况就是一种悲观的读法。stamp = sl.readLock();StampedLock的实现思想：CLH自旋锁：当锁申请失败时，不会立即将读线程挂起，在锁当中会维护一个等待线程队列，所有申请锁，但是没有成功的线程都记录在这个队列中。每一个节点（一个节点代表一个线程），保存一个标记位（locked），用于判断当前线程是否已经释放锁。当一个线程试图获得锁时，取得当前等待队列的尾部节点作为其前序节点。并使用类似如下代码判断前序节点是否已经成功释放锁while (pred.locked) {& &}这个循环就是不断等前面那个结点释放锁，这样的自旋使得当前线程不会被操作系统挂起，从而提高了性能。当然不会进行无休止的自旋，会在若干次自旋后挂起线程。
扫一扫加入本版微信群