3

好的，我一直在玩弄优秀的 JodaTime 库，试图实现一个通用案例零售/财政 (4-5-4) 日历。我已经找到了我公司的具体案例，但一般案例（主要是确定年初和闰年）是致命的；例如，有一组日期，两个会计年度（通常为 364 天）将在 1 个 ISO 年开始。

在确定年开始规则的过程中，我最终得到了一个抽象类和几个具体类来确定年开始，根据它们落在 ISO 闰日的哪一侧。

（精简）抽象类： 

private static abstract class SimpleFiscalYearEndPattern implements FiscalYearEndPattern {

    protected final int leapYearCountOffset;
    protected final int doomsdayOffset;

    private final int startingDayOfWeek;
    private final int yearOffset;
    private final long millisFromEpochToFiscalYearStart;
    private final long millisElapsedToEpochDividedByTwo;

    /**
     * Restricted constructor
     * @param fiscalYear
     * @param startingOn
     * @param inFirstWeek
     */
    protected SimpleFiscalYearEndPattern(final int fiscalYear, final LocalDate startingOn, final MonthDay inFirstWeek) {
        this.yearOffset = fiscalYear - startingOn.getYear();
        this.doomsdayOffset = getDoomsdayOffset(inFirstWeek);
        this.startingDayOfWeek = startingOn.getDayOfWeek();

        final int startingDoomsday = getDoomsdayOffset(new MonthDay(startingOn, REFERENCE_CHRONOLOGY));
        // If the starting doomsday is a later day-of-week, it needs to become negative.
        this.leapYearCountOffset = calculateLeapYearCountOffset(startingDoomsday : doomsdayOffset, doomsdayOffset);

        final int leapYearsBefore = getPreviousLeapYears(fiscalYearBeforeEpoch);
    }
}

（缩减）具体课程（适用于 1/7 - 2/28 范围内的日期）： 

private static final class BeforeLeapYearEndPattern extends SimpleFiscalYearEndPattern {

    private static final int FIRST_YEAR_LEAP_YEAR_OFFSET = -1;

    private BeforeLeapYearEndPattern(final int fiscalYear, final LocalDate startingOn, final MonthDay onOrBefore) {
        super(fiscalYear, startingOn, onOrBefore);
    }

    public static final BeforeLeapYearEndPattern create(final int fiscalYear, final LocalDate startingOn, final MonthDay onOrBefore) {
        return new BeforeLeapYearEndPattern(fiscalYear, startingOn, onOrBefore);
    }

    /* (non-Javadoc)
     * @see ext.site.time.chrono.FiscalYearEndPatternBuilder.SimpleFiscalYearEndPattern#getPreviousLeapYears(int)
     */
    @Override
    protected int getPreviousLeapYears(final int isoYear) {
        // Formula gets count of leap years, including current, so subtract a year first.
        final int previousYear = isoYear - 1;
        // If the doomsday offset is -1, then the first year is a leap year.
        return (previousYear + leapYearCountOffset + (previousYear / 4) - (previousYear / 100) + (previousYear / 400)) / 7 + (leapYearCountOffset == FIRST_YEAR_LEAP_YEAR_OFFSET ? 1 : 0);
    }

如果您注意到，我使用leapYearCountOffset了在抽象超类 in 中定义（作为最终变量）的 ，getPreviousLeapYears()然后从超类构造函数中调用它。我不想在超类构造函数中重复这个公式——它对于 3/1-12/31 范围内的日期是不同的；我也不想将实例变量放在具体的子类中 - 其他计算仍然需要leapYearCountOffset。

问题是：leapYearCountOffset从构造函数调用（子类）方法时的状态是什么？它是否以任何方式得到保证，或者编译器会随心所欲地改变它？我怎么能测试它来找出答案呢？我已经知道编译器可以自由地重新安排一些语句，但是（可能吗？）这会发生在这里吗？

4

4 回答 4

4

变量的保证之一final是编译器不会让您在分配它们之前访问它们。所以，如果它编译（它应该），你很高兴！

于 2012-04-12T18:26:11.100 回答
2

由于在分配getPreviousLeapYears后调用，将被正确初始化并看到正确的值。leapYearCountOffsetleapYearCountOffsetgetPreviousLeapYears

Java 留下了确保final在构造函数期间调用的代码访问的变量在首次访问之前正确初始化的负担。如果未正确初始化，在构造函数期间调用的代码将看到该字段类型的零值。

该程序

public class Foo {
  protected final int x;
  Foo() {
    foo();
    this.x = 1;
    foo();
  }
  void foo() { System.out.println(this.x); }
  public static void main(String[] argv) { new Foo(); }
}

印刷

0
1

因为x在第一次调用时没有初始化foo，但如上所述，你没有这个问题。

JLS 说在构造函数中每次使用 final 都必须在初始化之后，但对其他方法不做这样的保证。考虑

abstract class C {
  public final int x;

  C() {
    this.x = f();
  }

  abstract int f();
}

对于确保x在每次使用之前初始化的语言，它需要确保不存在子类

class D extends C {
  int f() {
    return this.x;
  }
}

这需要对类进行全局推理，这将与 Java 的动态链接不一致，并为语言规范增加很多复杂性。

于 2012-04-12T18:26:22.417 回答
0

虽然leapYearCountOffset保证有它的最终价值，但这仍然是一个等待发生的意外。该方法getPreviousLeapYears在子类初始化开始之前执行，因此子类中的任何变量都将具有其默认值（0 或 null）。

现在没有危险，但是如果有人进来改变BeforeLeapYearEndPattern了，也许通过添加一个新的final实例变量，然后使用它getPreviousLeapYears，你会受到伤害。

于 2012-04-12T18:37:54.297 回答
0

看起来这个问题是由线程内和线程间语义之间的混淆引起的。

只要您在单个线程中运行有问题的代码，一切都会按您的预期工作：代码重新排序不会有明显的影响。

final字段也是如此。final字段为并发访问提供了额外的保证，这些保证只有在构造函数完成后才会生效。这就是为什么不建议final在构造函数完成之前让其他线程可以访问字段的原因。但只要您不尝试从其他线程访问有问题的字段，这并不重要。

但是，我同意从超类的构造函数调用子类方法是一种不好的做法，因为此时没有初始化子类字段。

于 2012-04-12T18:48:14.163 回答